Record carrier, system, method and program for conditional access to data stored on the record carrier

ABSTRACT

The record carrier of the present invention has a storage area for storing data. The record carrier receives an access requisition to the storage area from a terminal device having the record carrier attached thereto, acquires an access condition indicating authorization to access the storage area, judges whether or not the access requisition satisfies the access condition. When confirming that the access requisition does not satisfy the access condition, the record carrier prevents the access to the storage area. This allows for preventing an unauthorized user from accessing the data stored inside in the case where the record carrier is lost.

TECHNICAL FIELD

The present invention relates to a record carrier, in particular to atechnology for protecting data stored in the record carrier in the case,for example, when the record carrier is lost.

BACKGROUND ART

Late years, portable information devices having a card slot in which arecord carrier, for example an IC card and a memory card, is placed havecome into wide use as the multifunctionality of portable informationdevices, such as cellular phones and PDAs (Personal Digital Assistants),has been advanced.

Recorded onto such record carriers attached to portable informationdevices are for instance telephone directory data, schedule directorydata, and image data taken by digital cameras. The telephone directorydata contains personal information including the user's telephone numberand mail address, and names of the user's acquaintances, their telephonenumbers, mail addresses, and home addresses and so on.

Therefore, a mechanism of proper protection is required so that anyoneelse other than the user cannot access such data recorded onto therecord carrier even if the record carrier or the portable informationdevice having the record carrier attached thereto is lost.

A record carrier disclosed in Patent Document 1 stores personal data aswell as a specific invalidation code. When a cellular phone having therecord carrier attached thereto is stolen or lost, the user can send theinvalidation code to the cellular phone by telephoning to the cellularphone. The cellular phone receives the invalidation code, and thentransfers this to the record carrier. The record carrier receives theinvalidation code from the cellular phone, and judges whether or not thereceived invalidation code matches the invalidation code stored in therecord carrier in advance. When these two match, then the record carrierlocks the personal data and makes it unusable. Herewith, the personaldata stored in the card is protected.

[PATENT DOCUMENT 1: Japanese Laid-Open Patent Application No.H11-177682]

DISCLOSURE OF THE INVENTION

The above technology assumes that the cellular phone having the recordcarrier attached thereto is in a state capable of receiving theinvalidation code transmitted from outside. Therefore, if the recordcarrier is taken out from the missing cellular phone and attached toanother terminal device that can be used offline, the record carrierdoes not receive the invalidation code and thereby personal data storedtherein may be seen by others.

In view of the above problem, the present invention aims at providing arecord carrier and a data protection system capable of protectingpersonal data stored in the record carrier even if the record carrier isattached to another terminal device which can be used offline.

In order to achieve the above object, the present invention is a recordcarrier comprising: a storage unit; a requisition receiving unitoperable to receive, from a terminal device having the record carrierattached thereto, a requisition for access to the storage unit; anacquisition unit operable to acquire an access condition indicatingwhether or not the terminal device is authorized to access the storageunit; a judging unit operable to judge whether or not the requisitionsatisfies the access condition; and a prevention unit operable toprevent the access of the terminal device to the storage unit when thejudging unit judges that the requisition does not satisfy the accesscondition.

According to this structure, even if the record carrier receives arequisition for access from the terminal device having the recordcarrier attached thereto, the record carrier is capable of denyingaccess of the terminal device to the storage area when the accesscondition is not satisfied.

Here, the record carrier may further comprise an access conditionstorage unit operable to store the access condition, wherein theacquisition unit acquires the access condition from the access conditionstorage unit.

According to this structure, since the record carrier stores the accesscondition therein, the record carrier does not have to acquire fromoutside the access condition that serves as judgment criteria, even ifthe terminal device having the record carrier attached thereto is aterminal device that can be used offline. Thus, the record carrier iscapable of judging whether or not the requisition for access satisfiesthe access condition, regardless of the environment in which theterminal device is placed. Consequently, even if the terminal device canbe used offline, the record carrier is capable of denying access of theterminal device to the storage area when the access condition is notsatisfied.

Here, the access condition may include an identifier list including oneor more identifiers which respectively identify one or more devicesauthorized to access the storage unit. Then, the requisition includes arequiring device identifier for identifying the terminal device. Thejudging unit judges that, (i) when an identifier matching the requiringdevice identifier is included in the identifier list, the requisitionsatisfies the access condition, and (ii) when an identifier matching therequiring device identifier is not included in the identifier list, therequisition does not satisfy the access condition.

According to this structure, the record carrier registers in advance adevice ID of the authorized terminal device with the list. Thisprevents, in the case where the record carrier is lost, the internaldata to be read out by attaching the record carrier to another terminaldevice.

Here, the access condition may include an identifier list including oneor more identifiers and one or more sets of number information whichcorrespond one-to-one with the identifiers respectively, the one or moreidentifiers identifying one or more devices authorized to access thestorage unit, each set of number information indicating a count ofaccesses available for the corresponding device to access the storageunit. Then, the requisition includes a requiring device identifier foridentifying the terminal device. The judging unit includes: a holdingunit operable to hold a count of accesses indicating how many times theterminal device has accessed the storage unit; a 1st judging subunitoperable to judge whether or not an identifier matching the requiringdevice identifier is included in the identifier list; and a 2nd judgingsubunit operable to judge, when the 1st judging subunit judges that thematching identifier is included, whether or not a count indicated by aset of number information corresponding to the matching identifier islarger than the count of accesses held by the holding unit. The judgingunit judges that, (i) when either one of a judgment result by the 1stjudging subunit and a judgment result by the 2nd judging subunit isnegative, the requisition does not satisfy the access condition, and(ii) when both the judgment results are positive, the requisitionsatisfies the access condition.

According to this structure, the record carrier registers in advancedevice IDs of the authorized terminal devices with the list. This way,in the case where the record carrier is lost, it is prevented that theinternal data is read out by attaching the record carrier to anotherterminal device. In addition, by managing the number of accesses to thestorage area, the record carrier can be used as a mechanism forprotecting copyrights of data stored in the storage area.

Here, the access condition may include an identifier list including oneor more identifiers and one or more sets of period information whichcorrespond one-to-one with the identifiers respectively, the one or moreidentifiers identifying one or more devices authorized to access thestorage unit, each set of period information indicating a time periodavailable for the corresponding device to access the storage unit. Then,the requisition includes a requiring device identifier for identifyingthe terminal device. The judging unit includes: a time managing unitoperable to manage a current data and time; a 1st judging subunitoperable to judge whether or not an identifier matching the requiringdevice identifier is included in the identifier list; and a 2nd judgingsubunit operable to judge, when the 1st judging subunit judges that thematching identifier is included, whether or not the current time iswithin a time period indicated by a set of period informationcorresponding to the matching identifier. The judging unit judges that,(i) when either one of a judgment result by the 1st judging subunit anda judgment result by the 2nd judging subunit is negative, therequisition does not satisfy the access condition, and (ii) when boththe judgment results are positive, the requisition satisfies the accesscondition.

According to this structure, the record carrier registers in advancedevice IDs of the authorized terminal devices with the list. This way,in the case where the record carrier is lost, it is prevented that theinternal data is read out by attaching the record carriers to anotherterminal device. In addition, by managing the time period allowed toaccess the storage area, the record carrier can be used as a mechanismfor protecting copyrights of data stored in the storage area.

Here, the storage unit may include a plurality of memory blocks. Then,the access condition includes an identifier list including one or moreidentifiers and one or more sets of memory block information, whichcorrespond one-to-one with the identifiers respectively identifying oneor more devices authorized to access the storage unit, the sets ofmemory block information each indicating one or more of the memoryblocks available for each of the corresponding devices to access. Therequisition includes a requiring device identifier for identifying theterminal device and memory block specifying information for specifyingone of the memory blocks. The judging unit includes: a 1st judgingsubunit operable to judge whether or not an identifier matching therequiring device identifier is included in the identifier list; and a2nd judging subunit operable to judge, when the 1st judging subunitjudges that the matching identifier is included, whether or not thememory block specified by the memory block specifying information isincluded in the one or more of the memory blocks indicated by a set ofthe memory block information corresponding to the matching identifier.The judging unit judges that, (i) when either one of a judgment resultby the 1st judging subunit and a judgment result by the 2nd judgingsubunit is negative, the requisition does not satisfy the accesscondition, and (ii) when both the judgment results are positive, therequisition satisfies the access condition.

According to this structure, the record carrier registers in advancedevice IDs of the authorized terminal devices with the list. This way,in the case where the record carrier is lost, it is presented that theinternal data is read out by attaching the record carrier to anotherterminal device. In addition, by managing information on the memoryblocks available for access, the record carrier can be used as amechanism for protecting copyrights of data stored with respect to eachmemory block.

Here, the storage unit may store one or more sets of program data. Then,the access condition includes an identifier list including one or moreidentifiers and one or more sets of program information, whichcorrespond one-to-one with the identifiers respectively identifying oneor more devices authorized to access the storage unit, the sets ofprogram information each indicating one or more sets of the program dataavailable for each of the corresponding devices to access. Therequisition includes a requiring device identifier for identifying theterminal device and program specifying information for specifying oneset of the program data. The judging unit includes: a 1st judgingsubunit operable to judge whether or not an identifier matching therequiring device identifiers included in the identifier list; and a 2ndjudging subunit operable to judge, when the 1st judging subunit judgesthat the matching identifier is included, whether or not the set ofprogram data specified by the program specifying information is includedin the one or more sets of the program data indicated by a set of theprogram information corresponding to the to the matching identifier. Thejudging unit judges that, (i) when either one of a judgment result bythe 1st judging subunit and a judgment result by the 2nd judging subunitis negative, the requisition does not satisfy the access condition, and(ii) when both the judgment results are positive, the requisitionsatisfies the access condition.

According to this structure, the record carrier registers in advancedevice IDs of the authorized terminal devices with the list. This way,in the case where the record carrier is lost, it is prevented that theinternal data is read out by attaching the record carrier to anotherterminal device. In addition, by managing the information on theapplication programs available for access, the record carrier can beused as a mechanism for protecting copyrights of application programsstored in the storage area.

Here, the access condition may include (i) an identifier list includingone or more identifiers which respectively identify one or more devicesauthorized to access the storage unit, and (ii) a biometrics listincluding one or more sets of biometric information or respectivelyidentifying one or more users authorized to access the storage unit.Then, the requisition includes a requiring device identifier foridentifying the terminal device and operator biometric informationindicating biometric information of an operator of the terminal device.The judging unit includes: a 1st judging subunit operable to judgewhether or not an identifier matching the requiring device identifier isincluded in the identifier list; and a 2nd judging subunit operable tojudge, when the 1st judging subunit judges that the matching identifieris included, whether or not a set of the biometric informationcorresponding to the operator biometric information is included in thebiometrics list. The judging unit judges that, (i) when either one of ajudgment result by the 1st judging subunit and a judgment result by the2nd judging subunit is negative, the requisition does not satisfy theaccess condition, and (ii) when both the judgment results are positive,the requisition satisfies the access condition.

According to this structure, the record carrier registers in advancedevice IDs of the authorized terminal devices with the list. This way,in the case where the record carrier is lost, it is prevented that theinternal data is read out by attaching the record carrier to anotherterminal device. In addition, the record carrier registers biometricinformation of the authorized user with the list in advance. Herewith,even if the record carrier is lost with attached to the authorizedterminal device, the implementation of user authentication prevents anunauthorized user from accessing data in the storage area.

Here, the access condition may include (i) an identifier list includingone or more identifiers which respectively identify one or more devicesauthorized to access the storage unit, and (ii) a password listincluding one or more sets of password information respectivelyspecified by one or more users authorized to access the storage unit.Then, the requisition includes a requiring device identifier foridentifying the terminal device and an entry password entered by anoperator of the terminal device. The judging unit includes: a 1stjudging subunit operable to judge whether or not an identifier matchingthe requiring device identifier is included in the identifier list; anda 2nd judging subunit operable to judge whether or not a passwordindicated by a set of password information corresponding to the entrypassword is included in the password list. The judging unit judges that,(i) when either one of a judgment result by the 1st judging subunit anda judgment result by the 2nd judging subunit is negative, therequisition does not satisfy the access condition, and (ii) when boththe judgment results are positive, the requisition satisfies the accesscondition.

According to this structure, the record carrier registers in advancedevice IDs of the authorized terminal devices with the list. This way,in the case where the record carrier is lost, it is prevented that theinternal data is read out by attaching the record carrier to anotherterminal device. In addition, the record carrier registers a passwordspecified by the authorized user with the list in advance. Herewith,even if the record carrier is lost with attached to the authorizedterminal device, the implementation of password verification prevents anunauthorized user from accessing data in the storage area.

Here, the record carrier may further comprise: an access conditionaccepting unit operable to accept the access condition from a terminaldevice having the record carrier attached thereto; and an accesscondition registration unit operable to register, when the terminaldevice is authorized, the access condition with the access conditionstorage unit.

According to this structure, the authorized terminal device registersthe access condition indicating that the terminal device itself isauthorized to access the storage area while other devices areunauthorized to access the storage area. Herewith, the data in thestorage area is protected when the record carrier is attached todifferent terminal devices.

Furthermore, the authorized terminal device registers not only itselfbut also other terminal devices used by the same user as accessauthorized devices. Herewith, the record carrier can be used on thoseterminal devices of the same user.

In order to accomplish the above object, the record carrier may furthercomprise: a communication unit operable to communicate with an accesscondition management server connected via a network, wherein theacquisition unit acquires the access condition from the access conditionmanagement server via the communication unit.

Namely, according to this structure, it is not the record carrier itselfbut the access condition management server that stores the accesscondition. Herewith, even if the record carrier is lost with attached tothe authorized terminal device, the access condition stored by theaccess condition management server can be rewritten so that the terminaldevice having the record carrier attached thereto cannot access thestorage area.

Here, the acquisition unit may acquire from the access conditionmanagement server via the communication unit, along with the accesscondition, signature data generated based on the access condition. Then,the record carrier may further comprise: a tamper detection unitoperable to examine the signature data using a verification key relevantto the access condition management server, and detect whether or not theaccess condition has been tampered; and a prohibition unit operable toprohibit, when the tamper detection detects that the access conditionhas been tampered, the judging unit from judging.

According to this structure, the record carrier is capable of judgingwhether the requisition for access is satisfied or not, using the accesscondition indeed sent from the access condition management server.

The present invention is also a data protection system comprising arecord carrier and a terminal device. The record carrier includes: astorage unit; a requisition receiving unit operable to receive, from aterminal device having the record carrier attached thereto, arequisition for access to the storage unit; an access condition onstorage unit operable to store an access condition indicating whether ornot the terminal device is authorized to access the storage unit; ajudging unit operable to judge whether or not the requisition satisfiesthe access condition; and a prevention unit operable to prevent theaccess to the storage unit when the judging unit judges the requisitiondoes not satisfy the access condition. The terminal device includes: arecord carrier interface operable to attach the record carrier thereto;an access requisition generation unit operable to generate therequisition of the record carrier to the storage unit; and an accessrequisition output unit operable to output, to the record carrier, thegenerated requisition for access.

According to this structure, since the record carrier stores the accesscondition therein, the record carrier does not have to acquire fromoutside the access condition that serves as judgment criteria, even ifthe terminal device having the record carrier attached thereto is aterminal device that can be used offline. Thus, the record carrier iscapable of judging whether or not the requisition for access satisfiesthe access condition, regardless of the environment in which theterminal device is placed. Consequently, even if the terminal device canbe used offline, the record carrier is capable of denying access of theterminal device to the storage area when the access condition is notsatisfied.

Here, the data protection system may further comprise an accesscondition registration server operable to register the access conditionwith the access condition storage unit of the record carrier via theterminal device having the record carrier attached thereto.

According to this structure, if the record carrier is attached to adevice capable of being connected with the access condition registrationserver, the access condition can be registered with the record carrier.

The present invention is also a data protection system comprising: arecord carrier; a terminal device; and an access condition managementserver. The record carrier includes: a storage unit; a requisitionreceiving unit operable to receive, from a terminal device having therecord carrier attached thereto, a requisition for access to the storageunit; an access condition storage unit operable to store an accesscondition indicating whether or not the terminal device is authorized toaccess the storage unit; a judging unit operable to judge whether or notthe requisition satisfies the access condition; and a prevention unitoperable to prevent the access to the storage unit when the judging unitjudges the requisition does not satisfy the access condition. Theterminal device includes: a record carrier interface operable to attachthe record carrier thereto; an access requisition generation unitoperable to generate the requisition of the record carrier to thestorage unit; and an access requisition output unit operable to output,to the record carrier, the generated requisition for access. The accesscondition management server connected, via a network, with the terminaldevice having the record carrier attached thereto, includes: an accesscondition storage unit operable to store the access condition; and anaccess condition transmission unit operable to transmit the accesscondition to the record carrier via the terminal device having therecord carrier attached thereto.

Namely, according to this structure, it is not the record carrier itselfbut the access condition management server that stores the accesscondition. Herewith, even if the record carrier is lost with attached tothe authorized terminal device, the access condition stored by theaccess condition management server can be rewritten so that the terminaldevice having the record carrier attached thereto cannot access thestorage area.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a structure of a data protection system 1;

FIG. 2 is a functional block diagram showing a structure of a recordcarrier 10;

FIG. 3 shows an internal structure of an access-limited area 13;

FIG. 4 is a functional block diagram showing a structure of a deviceinformation registration unit 14;

FIG. 5A shows a data structure of registration requisition data 120,FIG. 5B shows a data structure of a registration ID list 125, FIG. 5Cshows a data structure of deletion requisition data 130, and FIG. 5Dshows a data structure of a deletion ID list 135;

FIG. 6 shows a data structure of an access authorized device table 140;

FIG. 7 is a functional block diagram showing a structure of a controller16;

FIGS. 8A-8D show data structures of access requisitions 160, 170, 180and 190, respectively;

FIG. 9 shows a data structure of a table 200;

FIG. 10 is a functional block diagram showing a structure of a cellularphone 20;

FIG. 11 is a flowchart illustrating overall operations of the dataprotection system 1;

FIG. 12A is a flowchart illustrating operations of a registrationprocess of device information, and FIG. 12B is a flowchart illustratingoperations of a deletion process of device information;

FIG. 13 is a flowchart illustrating operations of a FIG. 14 is aflowchart illustrating operations of the registration process performedby the record carrier 10 (continuing to FIG. 15);

FIG. 15 is a flowchart illustrating operations of the registrationprocess performed by the record carrier 10 (continued from FIG. 14);

FIG. 16 is a flowchart illustrating operations of the registrationprocess performed by the cellular phone 20 (continuing to FIG. 17);

FIG. 17 is a flowchart illustrating operations of the registrationprocess performed by the cellular phone 20 (continued from FIG. 16);

FIG. 18 is a flowchart illustrating operations of the deletion processperformed by the record carrier 10 (continuing to FIG. 19);

FIG. 19 is a flowchart illustrating operations of the deletion processperformed by the record carrier 10 (continued from FIG. 18);

FIG. 20 is a flowchart illustrating operations of the deletion processperformed by the cellular phone 20;

FIG. 21 is a flowchart illustrating operations of a data access processperformed by the data protection system 1;

FIG. 22 is a flowchart illustrating operations of an accessauthorization process performed by the record carrier FIG. 23 is aflowchart illustrating operations of the access authorization processperformed by the record carrier 10 (continued from FIG. 22);

FIG. 24 shows a structure of a data protection system 1 a;

FIG. 25 is a functional block diagram showing a structure of a recordcarrier 10 a;

FIG. 26 is a functional block diagram showing a structure of a cellularphone 20 a and a registration server 60 a;

FIG. 27A shows a data structure of registration requisition data 310,and FIG. 27B shows a data structure of deletion requisition data 320;

FIG. 28 shows a structure of a data protection system 2;

FIG. 29 is a functional block diagram showing a structure of a recordcarrier 10 b and a management server 70 b;

FIG. 30 shows a data structure of an access authorized device table 400;

FIG. 31 is a flowchart illustrating overall operations of the dataprotection system 2; and

FIG. 32 is a flowchart illustrating operations of the data accessprocess in the data protection system 2.

BEST MODE FOR CARRYING OUT THE INVENTION [1] First Embodiment

The following gives a description of a data protection system 1according to the first embodiment of the present invention.

FIG. 1 shows a structure of the data protection system 1. As shown inthe figure, the data protection system 1 comprises a record carrier 10,a cellular phone 20, a PDA (Personal Digital Assistant) 30, a PC(Personal Computer) 40 and a cellular phone 50.

The record carrier 10 is a portable medium having a microprocessortherein. Here, it is assumed that the record carrier 10 is a memorycard, an IC card or the like, which is, for use, placed in a card slotof for example a cellular phone, a PDA, a PC, a digital camera, and acard reader/writer.

A SD (Secure Digital) memory card is an example of the memory card. SDmemory cards have a function of copyright protect called CPRM (ContentProtection for Recordable Media) built-in, and are suited for storingcontents such as music and images.

A SIM (Subscriber Identity Module) card is an example of the IC card.Cellular phone companies issue-SIM cards which are IC cards eachcontaining the contractant's information. The SIM cards are attached tocellular phones and used for user identification. By detaching the SIMcard from one cellular phone and placing it in another, a plurality ofcellular phones can be used under the name of the same contractant.

The cellular phone 20, PDA 30, PC 40, and cellular phone 50 are computersystems each having a microprocessor. In this specification, thesecellular phones, PDA and PC will be sometimes collectively called“terminal devices.”

These terminal devices each have a card slot, and input and outputinformation to/from the record carrier 10 when the record carrier 10 isplaced in the card slot. To each of the terminal devices, a device IDthat is a specific identifier for the terminal device is assigned.Device IDs of “ID_A,” “ID_B,” “ID_C” and “ID_E” are assigned to thecellular phone 20, the PDA 30, the PC 40, and the cellular phone 50,respectively. The details will be discussed later in this specification.

Note here that the present embodiment assumes that the record carrier 10was placed in the card slot of the cellular phone 20 in advance, andthen has been sold to the user of the cellular phone 20 in thiscondition. Additionally, the cellular phone 20, PDA 30 and PC 40 shallbe terminal devices all owned by the same user while the cellular phone50 shall be a terminal device owned by another individual.

<Structure>

1. Record Carrier 10

FIG. 2 shows a structure of the record carrier 10. As shown in thefigure, the record carrier 10 comprises a terminal I/F 11, a datastorage unit 12, a device information registration unit 14, a deviceinformation storage unit 15, and a controller 16. The data storage unit12 includes an access-limited area 13.

1.1 Terminal I/F 11

The terminal I/F 11 comprises connector pins and an interface driver.When the record carrier 10 is placed in the card slot of the cellularphone 20, the PDA 30, the PC 40 or the cellular phone 50, the terminalI/F 11 receives and sends various information from/to the relevantterminal device.

Specifically speaking, for example the terminal I/F 11 outputs, to thecontroller 16, an access requisition received from the terminal device,and outputs, to the device information registration unit 14,registration requisition data and deletion requisition data receivedfrom the terminal device.

1.2 Data Storage Unit 12

The data storage unit 12 is specifically speaking a flash memory, andstores programs and data. The data storage unit 12 can be accessed fromthe controller 16, and is capable of storing therein informationreceived from the controller 16 and outputting the stored information tothe controller 16 according to a requisition from the controller 16.Note that the data storage unit 12 includes the access-limited area 13which is an area used for storing highly confidential data and the like.

1.3 Access-Limited Area 13

The access-limited area 13 is a part of the data storage unit 12, andcomprises three memory blocks of Block 1, Block 2 and Block 3, as shownin FIG. 3. Memory areas of these memory blocks should be logicallyseparated from one another, but there is no need to be physicallyseparated.

Block 1 stores Application Program 1 (APP1), Application Program 2(APP2), address directory data and protected mail data. Block 2 storesschedule data, image data and so on. Block 3 stores Application Program3 (APP3) and the like.

These programs and data stored in each of the blocks are read out andwritten by the controller 16.

1.4 Device Information Registration Unit 14

The device information registration unit 14 comprises a microprocessorand the like, and registers access authorized device information withthe device information storage unit 15 according to the registrationrequisition received from the cellular phone 20. The access authorizeddevice information is information on terminal devices authorized toaccess the access-limited area 13. Furthermore, the device informationregistration unit 14 deletes already registered access authorized deviceinformation in the device information storage unit 15 according to thedeletion requisition received from the cellular phone 20.

FIG. 4 is a functional block diagram showing a structure of the deviceinformation registration unit 14. As shown in the figure, the deviceinformation registration unit 14 comprises a process-launch requisitionreceiving unit 101, a random number generation unit 102, a response dataverification unit 103, a public key acquisition unit 104, a random keygeneration unit 105, an encryption unit 106, processing-data acceptingunit 107, a signature verification unit 108, a password verificationunit 109, a decryption unit 110, and a data controller 111.

(a) The process-launch requisition receiving unit 101 receives aprocess-launch requisition from the cellular phone 20 via the terminalI/F 11. The process-launch requisition is information indicating alaunch of a registration process or a deletion process of the accessauthorized device information. When receiving the process-launchrequisition, the process-launch requisition receiving unit 101 outputsan instruction to the random number generation unit 102 to generate arandom number.

(b) When receiving the instruction for generating a random number fromthe process-launch requisition receiving unit 101, the random numbergeneration unit 102 generates a random number r. The random number r ischallenge data used for a challenge/response verification performed withthe cellular phone 20. The random number generation unit 102 outputs thegenerated random number r to the cellular phone 20 via the terminal I/F11 as well as to the response data verification unit 103.

(c) The response data verification unit 103 shares in advance acommon-key Kc and an encryption algorithm E₁ with the cellular phone 20.The response data verification unit 103 examine response data receivedfrom the cellular phone 20 via the terminal I/F 11 and fudges whether ornot the cellular phone 20 is an authorized terminal device.

Specifically speaking, the response data verification unit 103 receivesthe random number r, which is challenge data, from the random numbergeneration unit 102, and generates encrypted data C₁=E₁ (Kc, r) byapplying the encryption algorithm E₁ to the received random number rusing the common key Kc as an encryption key. Meanwhile, the responsedata verification unit 103 receives response data C₁′=E₁ (Kc, r) fromthe cellular phone 20 via the terminal I/F 11. Then, the response dataverification unit 103 compares the encrypted data C₁ and the responsedata C₁′. When these two match, the response data verification unit 103confirms that the cellular phone 20 is an authorized terminal device,and gives an instruction to the random key generation unit 105 togenerate a random key. When C₁ and C₁′ do not match, the response dataverification unit 103 confirms that the cellular phone 20 is anunauthorized terminal device and is sends an error message indicating“an authorization error” to the cellular phone 20 via the terminal I/F11. The encryption algorithm E₁ is not confined to any particularalgorithms, but one example of this is the DES (Data EncryptionStandard).

(d) The public key acquisition unit 104 acquires and holds a public keyPK₂₀ of the cellular phone 20. Here, no restrictions on how to acquirethe public key PK₂₀ are set. The public key PK₂₀ may be written to thepublic key acquisition unit 104 in advance, or may be acquired from thecellular phone 20 via the terminal I/F 11 according to, for example, theuser operation. The public key acquisition unit 104 receives aninstruction from the encryption unit 106 and outputs the public key PK₂₀to the encryption unit 106.

(e) When receiving, from the response data verification unit 103, theinstruction to generate a random key, the random key generation unit 105generates a random key Kr. The random key generation unit 105 outputsthe generated random key Kr to the encryption unit 106 as well as to thedecryption unit 110.

Note that in this specification random keys generated by the random keygeneration unit 105 are all denoted as “Kr,” however an actual randomkey Kr is key data randomly generated every time when the random keygeneration unit 105 receives, from the response data verification unit103, an instruction to generate a random key.

(f) The encryption unit 106 receives the random key Kr from the randomkey generation unit 105. When receiving the random key Kr, theencryption unit 106 directs the public key acquisition unit 104 tooutput the public key PK₂₀, and receives the public key PK₂₀ from thepublic key acquisition unit 104.

The encryption unit 106 generates an encrypted random key C₂=E₂(PK₂₀,Kr) by applying an encryption algorithm E₂ to the random key Kr usingthe public key PK₂₀ as an encryption key. The encryption unit 106outputs the generated encrypted random key C₂=E₂ (PK₂₀, Kr) to thecellular phone 20 via the terminal I/F 11. Here, the encryptionalgorithm E₂ is not confined to any particular algorithms, but oneexample of this is the RSA (Rivest-Shamir-Adleman) algorithm.

(g) The processing-data accepting unit 107 receives processing data fromthe cellular phone 20 via the terminal I/F 11, and outputs the receivedprocessing data to the signature verification unit 108.

The processing data received by the processing-data accepting unit 107from the cellular phone 20 is registration requisition data or deletionrequisition data. While the registration requisition data indicates theregistration process of the access authorized device information, thedeletion requisition data indicates the deletion process of the accessauthorized device information.

FIG. 5A shows an example of the registration requisition data. Theregistration requisition data 120 comprises a registration command 121,an encrypted registration ID list 122, a password 123, and signaturedata 124.

The registration command 121 is a command directing the data controller111, described hereinafter, to perform the registration process. Here,“/register” is given as a specific example of the registration command121.

The encrypted registration ID list 122 is encrypted data which isgenerated by applying an encryption algorithm E₃ to the registration IDlist 125 shown in FIG. 5B using the random key Kr as an encryption key.Here, the encrypted registration ID list 122 is denoted as E₃(Kr,registration ID list).

As shown in FIG. 5B, the registration ID list 125 comprises sets ofregistration information 126 and 127. Each set of the registrationinformation comprises a device ID, an available number of accesses, anaccess available time period, access available blocks and accessavailable applications.

The password 123 is data entered by the user of the cellular phone 20.

The signature data 124 is signature data generated by applying a digitalsignature algorithm to the registration command 121, the encryptedregistration ID list 122 and the password 123 using a signature key.Here, the signature key is key data for the digital signature, held bythe cellular phone 20.

The registration requisition data 120 is data generated by thecontroller 23 of the cellular phone 20. Accordingly, the details of theregistration requisition data 120 and registration ID list 125 will bediscussed later in the description of the cellular phone 20.

FIG. 5C shows an example of the deletion requisition data. The deletionrequisition data 130 comprises a deletion command 131, an encrypteddeletion ID list 132, a password 133, and signature data 134.

The deletion command 131 is a command directing the data controller 111,described hereinafter, to perform the deletion process. Here, “/delete”is given as a specific example of the deletion command 131.

The encrypted deletion ID list 132 is encrypted data which is generatedby applying the encryption algorithm E₃ to a deletion ID list 135 shownin FIG. 5D using the random key Kr as an encryption key. Here, theencrypted deletion ID list 132 is denoted as E₃(Kr, deletion ID list).The deletion ID list 135 comprises device IDs of “ID_C” and “ID_D.”

The password 133 is data entered by the operator of the cellular phone20.

The signature data 134 is signature data generated by applying a digitalsignature algorithm to the deletion command 131, the encrypted deletionID list 132, and the password 133 using a signature key.

Here, the random key Kr is key data randomly generated in the random keygeneration unit 105 for each process, as described above. Therefore, therandom key used for generating the encrypted registration ID list 122 isdifferent from the one used for generating the encrypted registration IDlist 132.

Note that the deletion requisition data 130 is data generated by thecontroller, 23 of the cellular phone 20. Accordingly, the details of thedeletion requisition data 130 will be discussed later in the descriptionof the cellular phone 20.

(h) The signature verification unit 108 holds a verification key thereinin advance. The verification key corresponds to the signature key heldby the cellular phone 20, and is key data used to verify the signaturedata outputted from the cellular phone 20.

The signature verification unit 108 receives the processing data fromthe processing-data accepting unit 107, examines the legitimacy of thesignature data included in the received processing data, and judgeswhether or not the processing data is indeed data generated by thecellular phone 20.

When the legitimacy of the signature data is verified, the signatureverification unit 108 outputs the processing data to the passwordverification unit 109. Contrarily, if the legitimacy of the signaturedata is not verified, the signature verification unit 108 informscellular phone 20 accordingly via the terminal I/F 11 and discards theprocessing data.

To give a specific example, suppose that the processing data receivedfrom the processing data accepting unit 107 is the registrationrequisition data 120 shown in FIG. 5A. The signature verification unit108 examines the legitimacy of the signature data “Sig_A” using theverification key. When the legitimacy of the signature data “Sig_A” isverified, the signature verification unit 108 outputs the registrationrequisition data 120 to the password verification unit 109. If theprocessing data received from the processing-data accepting unit 107 isthe deletion requisition data 130 shown in FIG. 5C, the signatureverification unit 108 examines the legitimacy of the signature data“Sig_A′” using the verification key. When the legitimacy of thesignature data “Sig_A′” is verified, the signature verification unit 108outputs the deletion requisition data 130 to the password verificationunit 109.

The algorithm used in the signature verification unit 108 for verifyingsignatures is a digital signature standard using a public-key encryptionscheme. The explanation for this algorithm is omitted-since it isfeasible with a well-known technology.

(i) The password verification unit 109 receives the processing data fromthe signature verification unit 108. Furthermore, the passwordverification unit 109 reads out a correct password from the deviceinformation storage unit 15, and judges whether or not the passwordincluded in the processing data matches the correct password.

When the password included in the processing data, namely the passwordentered by the operator of the cellular phone 20, matches the correctpassword, the password verification unit 109 outputs the processing datato the decryption unit 110. If the password included in the processingdata does not match the correct password, the password verification unit109 informs the cellular phone 20 accordingly via the terminal I/F 11and discards the processing data.

To give a specific example, suppose that the processing data receivedfrom the signature verification unit 108 is the registration requisitiondata 120 shown in FIG. 5A. The password verification unit 109 extracts“PW_A” from the registration requisition data 120, and judges whether ornot “PW_A” matches the correct password. When “PW_A” matches the correctpassword, the password verification unit 109 outputs the registrationrequisition data 120 to the decryption unit 110. If the processing datareceived from the signature verification unit 108 is the deletionrequisition data 130 shown in FIG. 5C, the password verification unit109 extracts “PW_A′” and judges whether or not “PW_A′” matches thecorrect password. When “PW_A′” matches the correct password, thepassword verification unit 109 outputs the deletion requisition data 130to the decryption unit 110.

(j) The decryption unit 110 receives the processing data from thepassword verification unit 109 and further receives the random key Krfrom the random key generation unit 105.

The decryption unit 110 extracts the encrypted processing data, anddecrypts the encrypted registration ID list or the encrypted deletion IDlist by applying a decryption algorithm D₃ using the random key Krreceived from the random key generation unit 105 as a decryption key inorder to obtain the registration ID list or the deletion ID list. Here,the decryption algorithm D₃ is an algorithm used for decrypting datawhich has been encrypted with the encryption algorithm E₃.

The decryption unit 110 outputs, to the data controller 111, theregistration command and the decrypted registration ID list, or thedeletion command and the decrypted deletion ID list.

To give a specific example, when receiving the registration requisitiondata 120 from the password verification unit 109, the decryption unit110 extracts the encrypted registration ID list 122 from theregistration requisition data 120, and decrypts the encryptedregistration ID list 122 in order to obtain the registration ID list 125shown in FIG. 5B. The decryption unit 110 outputs the registrationcommand 121 and the registration ID list 125 to the data controller 111.

When receiving the deletion requisition data 130 from the passwordverification unit 109, the decryption unit 110 extracts the encrypteddeletion ID list 132 from the deletion requisition data 130, anddecrypts the encrypted deletion ID last 132 in order to obtain thedeletion ID list 135 shown in FIG. 5D. The decryption unit 110 outputsthe deletion command 131 and the deletion ID list 135 to the datacontroller 111.

(k) The data controller 111 performs registration and deletion of theaccess authorized device information.

More specifically, the data controller 111 receives the registrationcommand and the registration ID list from the decryption unit 110. Ifthe registration information included in the registration ID list hasnot yet been registered with an access authorized device table 140stored in the device information storage unit 15, the data controller111 registers the registration information with the access authorizeddevice table 140 as access authorized device information.

The data controller 111 also receives the deletion command and thedeletion ID list from the decryption unit 110. If the device ID includedin the deletion ID list has already been registered with the accessauthorized device table 140, the data controller 111 deletes the accessauthorized device information which includes the device ID from theaccess authorized device table 140.

Note that the access authorized device table 140 will be describedlater.

1.5 Device Information Storage Unit 15

The device information storage unit 15 stores a password and the accessauthorized device table 140.

It is assumed that the password stored in the device information storageunit 15 is a unique password set at the time when the record carrier 10is manufactured or shipped and written to the device information storageunit 15.

Note that only the user who has purchased the record carrier 10 shallknow the password stored in the device information storage unit 15. Forexample, the following scheme may be adopted: within the packaging box,the password stored in the device information storage unit 15 is writtenin a place that cannot be seen unless the packaging box is opened. Inthis case, the user cannot obtain the password until the/she purchasesthe record carrier 10 and then opens the packaging box.

FIG. 6 shows a data structure of the access authorized device table 140.The access authorized device table 140 comprises sets of accessauthorized device information 141, 142 and 143, each of which includes adevice ID, an available number of accesses, an access available timeperiod, access available blocks, and access available applications.

The device ID is an identifier by which a device authorized to accessthe access-limited area 13 of the data storage unit 12 can be uniquelyidentified. The available number of accesses is the number of times thatthe corresponding device is authorized to access the access-limited area13. The access available time period is a time period during which thecorresponding device is authorized to access the access-limited area 13.The access available blocks are, within the access-limited area 13,memory blocks that the corresponding device is authorized to access. Theaccess available applications are application programs that thecorresponding device is authorized to access.

According to FIG. 6, devices authorized to access the access-limitedarea 13 are those, respectively having a device ID of “ID_A,” a deviceID of “ID_B” and a device ID of “ID_C.”

According to the access authorized device information 141, the devicehaving the device ID “ID_A” (cellular phone 20) is “unlimited” in allrespects, i.e. the available number of accesses, the access availabletime period, the access available blocks and the access availableapplications. Therefore, this device is authorized to access theaccess-limited area 13 without any restriction.

The access authorized device information 142 indicates that the devicehaving the device ID “ID_B” (PDA 30) has: “3” in the available number ofaccesses, “Jan. 8, 2004-Jul. 31, 2005” in the access available timeperiod, “Block 2? in the access available blocks, and “-” in the accessavailable applications. Therefore, this device is authorized to accessonly Block 2 up to three times during the time period between Aug. 1,2004 and Jul. 31, 2005.

The access authorized device information 143 indicates that the devicehaving the device ID “ID_C” (PC 40) has: “5”in the available number ofaccesses, “Aug. 1, 2004-Jul. 31, 2006” in the access available timeperiod, “Block 1 and Block 2” in the access available blocks, and “APP1”in the access available applications. Therefore, this device isauthorized to access only Blocks 1 and 2 up to five times during thetime period between Aug. 1, 2004 and Jul. 31, 2006, provided that theapplication program which the device is authorized to access is only theApplication Program 1 (APP1).

Each set of the access authorized device information is registered withor deleted from the access authorized device table 140 by the deviceinformation registration unit 14. Additionally, each set of the accessauthorized device information is used by the controller 16 for accessauthorization which is implemented in response to an access requisition.

1.6 Controller 16

The controller 16 comprises a microprocessor and the like. Whenreceiving, from the terminal I/F 11, the access requisition to theaccess-limited area 13, the controller 16 refers to the accessauthorized device table 140 stored in the device information storageunit 15, and judges whether to allow access to the access-limited area13 in response to the access requisition. The following will give adetailed description of the controller 16.

FIG. 7 is a functional block diagram illustrating a structure of thecontroller 16. As shown in the figure, the controller 16 comprises aprocess-launch requisition receiving unit 150, a public key acquisitionunit 151, a random key generation unit 152, an encryption unit 153, anaccess requisition receiving unit 154, a decryption unit 155, a judgingunit 156, a date management unit 157, a memory access unit 158 and adata input/output unit 159.

(a) The process-launch requisition receiving unit 150 receives aprocess-launch requisition, via the terminal I/F 11, from a terminaldevice having the record carrier 10 attached thereto. The process-launchrequisition is information indicating a launch of the access requisitionprocess to the access-limited area 13. When receiving the process-launchrequisition, the process-launch requisition receiving-unit 150 outputsan instruction to the public key acquisition unit 151 to acquire thepublic key of the terminal device as well as an instruction to therandom key generation unit 152 to generate a random key.

(b) When receiving the instruction to acquire the public key from theprocess-launch requisition receiving unit 150, the public keyacquisition unit 151 acquires the public key PKN of the terminal device,via the terminal I/F 11, from the terminal device having the recordcarrier 10 attached thereto, where N=20, 30, 40 or 50. PK₂₀, PK₃₀, PK₄₀and PK₅₀ are public keys of the cellular phone 20, the PDA 30, the PC 40and the cellular phone 50, respectively. In the case where the recordcarrier 10 is placed in the card slot of, for example, the cellularphone 20, the public key acquisition unit 151 acquires the public keyPK₂₀ from the cellular phone 20. The public key acquisition unit 151outputs the acquired public key PKN to the encryption unit 153.

(c) When receiving, from the process-launch requisition receiving unit150, the instruction to generate a random key, the random key generationunit 152 generates a random key Kr. The random key generation unit 152outputs the generated random key Kr to the encryption unit 153 as wellas to the decryption unit 155.

(d) The encryption unit 153 receives the public key PK_(N) from thepublic key acquisition unit 151 and the random key Kr from the randomkey generation unit 152. The encryption unit 153 generates an encryptedrandom key C₄=E₄ (PK_(N), Kr) by applying an encryption algorithm E₄ tothe random key Kr using public key PK_(N) as an encryption key. Theencryption unit 153 outputs the encrypted random key C₄=E₄ (PK_(N), Kr)to the terminal device via the terminal I/F 11. In the case where therecord carrier 10 is placed in the card slot of, for example, thecellular phone 20, the encryption unit 153 generates the encryptedrandom key C₄=E₄(PK₂₀, Kr), and outputs the encrypted random key C₄ tothe cellular phone 20 via the terminal I/F 11.

The encryption algorithm C₄ is not confined to any particular algorithm,but one example of this is the RSA.

(e) When receiving an access requisition from the terminal device viathe terminal I/F 11, the access requisition receiving unit 154 outputsthe received access requisition to the decryption unit 155.

FIG. 8A shows an example of the access requisition received by theaccess requisition receiving unit 154 from the cellular phone 20. Theaccess requisition 160 comprises an access command 161, an encrypteddevice ID 162 and required-data identifying information 163.

Similarly, FIG. 8B shows an example of an access requisition 170received from the PDA 30. FIG. 8C shows an example of an accessrequisition 180 received from the PC 40. FIG. 8D shows an example of anaccess requisition 190 received from the cellular phone 50.

Such an access requisition is data generated by each of the terminaldevices. Accordingly, detailed explanations of the access requisitions160, 170, 180 and 190 will be respectively given later.

(f) The decryption unit 155 receives the random key Kr from the randomkey generation unit 152 and the access requisition from the accessrequisition receiving unit 154. The decryption unit 155 extracts anencrypted device ID from the access requisition, and decrypts theencrypted device ID by applying a decryption algorithm D₅ using therandom key Kr as a decryption algorithm D₅ is an algorithm used fordecrypting data which has been encrypted with the encryption algorithmE₅. The decryption unit 155 outputs, to the judging unit 156, the accesscommand, the decrypted device ID and the required-data identifyinginformation.

To give a specific example, when receiving the access requisition 160shown in FIG. 8A from the access requisition receiving unit 154, thedecryption unit 155 extracts an encrypted device ID 162 “E₅(Kr, ID_A)”from the access requisition 160, and decrypts the encrypted device ID162 by applying the decryption algorithm D₅ using the random key Kr as adecryption key in order to obtain “ID_A.” The decryption unit 155outputs, to the judging unit 156, the access command 161 “/access,” thedevice ID “ID_A” and the required-data identifying information 163“address directory.”

(g) The judging unit 156 receives the access command, the device ID andthe required-data identifying information from the decryption unit 155.The judging unit 156 judges whether or not the terminal device havingthe received device ID is authorized to, access data identified by thereceived required-data identifying information.

Additionally, the judging unit 156 stores a table 200 shown in FIG. 9.The table 200 is a table showing the correspondence between blocknumbers of memory blocks in the access-limited area 13 and dataidentifying information of data stored in the respective memory blocks.The judging unit 156 also stores a table showing the correspondencebetween device IDs and their number of times already accessed. Thenumber of times already accessed is the number of times that a terminaldevice having the corresponding device ID has accessed the accesslimiting area 13. Note that this table is not illustrated.

The following will describe access authorization performed by thejudging unit 156, with the use of specific examples.

The judging unit 156 receives, from the decryption unit 155, the accesscommand 161 “/access,” “ID_A” decrypted by the decryption unit 155, andthe required-data identifying information 163 “address directory.” Thejudging unit 156 reads out, from the access authorized device table 140stored in the device information storage unit 15, access authorizeddevice information 141 which includes the device ID “ID_A.” Furthermore,the judging unit 156 reads out date information indicating the currentdate from the date management unit 157.

From the access authorized device information 141, the date informationand the table 200, the judging unit 156 judges whether or not thecellular phone 20 having the device ID “ID_A” is authorized to access“address directory.” The authorization process will be discussed indetail later.

Here, the cellular phone 20 is authorized to access to the addressdirectory. Therefore, the judging unit 156 directs the memory accessunit 158 to read out the address directory data (FIG. 3) from theaccess-limited area 13 and output the address directory data to thecellular phone 20 via the data input/output unit 159.

Here, if the cellular phone 20 is not authorized to access the addressdirectory, the judging unit 156 outputs, to the cellular phone 20 viathe terminal I/F 11, an error message informing that the cellular phone20 is not authorized to access the specified data.

(h) The date management unit 157 manages date information indicating thecurrent date.

(i) The memory access unit 158 stores the correspondence between thedata identifying information and memory addresses, each of whichindicates a location within the data storage unit 12 which stores dataidentified by the data identifying information. When receiving theaccess command and the data identifying information from the judgingunit 156, the memory access unit 158 acquires a memory addresscorresponding to the received data identifying information. The memoryaccess unit 158 reads out data from the location indicated by theacquired memory address, and outputs the readout data to the datainput/output unit 159.

(j) The data input/output unit 159 exchanges information between theterminal I/F 11 and the memory access unit 158.

2. Cellular Phone 20

FIG. 10 is a functional black diagram illustrating a structure of thecellular phone 20. As shown in the figure, the cellular phone 20comprises a record carrier I/F 21, a device ID storage unit 22, acontroller 23, an external input I/F 24 and a display unit 25.

Specifically speaking, the cellular phone 20 has an antenna, a radiocommunication unit, a microphone, a speaker and so on, and is a mobilephone establishing radio communication. Since such functions as acellular phone are feasible with a well-known technology, thesecomponents are omitted from FIG. 10.

2.1 Record Carrier I/F 21

The record carrier I/F 21 comprises a memory card slot and such, andreceives and sends various information from/to the record carrier 10placed in the memory card slot.

2.2 Device ID Storage Unit 22

The device ID storage unit 22 stores the device ID “ID_A” by which thecellular phone 20 is uniquely identified. Specifically speaking a serialnumber or a telephone number is used as the device ID.

2.3 Controller 23

As shown in FIG. 10, the controller 23 comprises a process-launchrequisition generation unit 211, a response data generation unit 212, adecryption unit 213, an encryption unit 214, a processing datageneration unit 215, a signature generation unit 216, an accessrequisition generation unit 217 and a data output unit 218.

(a) When receiving, from the external input I/F 24, an input signalindicating a registration requisition, a deletion requisition, or a dataaccess requisition, the process-launch requisition generation unit 211generates a process-launch requisition, and outputs the generatedprocess-launch requisition to the record carrier 10 via the recordcarrier I/F 21.

(b) The response data generation unit 212 shares the common key Kc andthe encryption algorithm E₁ with the record carrier 10 in advance.

The response data generation unit 212 receives, from the record carrier10 via the record carrier I/F 21, the random number r which is thechallenge data, and generates the response data C₁′=E₁(Kc, r) byapplying the encryption algorithm E₁ to the received random number rusing the common key Kc as an encryption key. The response datageneration unit 212 outputs the generated response data C₁′ to therecord carrier 10 via the record carrier I/F 21.

(c) The decryption unit 213 holds in confidence a secret key SK₂₀corresponding to the public key PK₂₀.

In the registration and deletion processes, the decryption unit 213receives the encrypted random key C₂=E₂(PK₂₀, Kr) from the recordcarrier 10 via the record carrier I/F 21. The encrypted random keyC₂=E₂(PK₂₀; Kr) is data in which the random key Kr has been encryptedwith the public key PK₂₀ of the cellular phone 20. The decryption unit213 decrypts the encrypted random key C₂ by applying a decryptionalgorithm D₂ using the secret key SK₂₀ as a decryption key in order toobtain the random key Kr. Here, the decryption algorithm D₂ is analgorithm used for decrypting data which has been encrypted with theencryption algorithm E₂. The decryption unit 213 outputs the decryptedrandom key Kr to the encryption unit 214.

In the access requisition process, the decryption unit 213 receives theencrypted random key C₄=E₄(PK₂₀, Kr) from the record carrier 10 via therecord carrier I/F 21. The encrypted random key C₄=E₄(PK₂₀, Kr) is datain which the random key Kr has been encrypted with the public key PK₂₀of the cellular phone 20. The decryption unit 213 decrypts the encryptedrandom key C₄ by applying the decryption algorithm D₄ using the secretkey SK₂₀ as a decryption key in order to obtain the random key Kr. Here,the decryption algorithm D₄ is an algorithm used for decrypting datawhich has been encrypted with the encryption algorithm E₄. Thedecryption unit 213 outputs the decrypted random key Kr to theencryption unit 214.

(d) In the registration process, the encryption unit 214 receives theregistration ID list from the processing data unit 213. The encryptionunit 214 generates an encrypted registration ID list by applying theencryption algorithm E₃ to the registration ID list using the random keyKr as an encryption key. Specifically speaking, the encryption unit 214receives the registration ID list 125 shown in FIG. 5B from theprocessing data generation unit 215, and generates the encryptedregistration ID list by encrypting the registration ID list 125. Theencryption unit 214 outputs the encrypted registration ID list to theprocessing data generation unit 215.

Similarly, in the deletion process, the encryption unit 214 generates anencrypted deletion ID list by encrypting the deletion ID list.Specifically speaking, the encryption unit 214 receives the deletion IDlist 135 shown in FIG. 5D from the processing data generation unit 215,and generates the encryption deletion list by encrypting the deletion IDlist 135. The encryption unit 214 outputs the encrypted deletion ID listto the processing data generation unit 215.

In the access requisition process, the encryption unit 214 reads out thedevice ID “ID_A” from the device ID storage unit 22, and furtherreceives the random key Kr from the decryption unit 213. The encryptionunit 214 generates the encrypted device ID “E₅ (Kr, ID_A)” by applyingthe encryption algorithm E₅ to “ID_A” using the random key Kr as anencryption key, and outputs the encrypted device ID to the accessrequisition generation unit 217.

(e) The processing data generation unit 215 generates registrationrequisition data and deletion requisition data.

(e-1) Generating Registration Requisition Data 120

Here, a process of generating the registration requisition data 120shown in FIG. 5A is described as a specific example.

The processing data generation unit 215 holds in advance controlinformation on the registration requisition data therein. The controlinformation is used for generating the registration requisition data. Inthe control information, only the registration command 121 “/register”of the registration requisition data 120 is written and the encryptedregistration ID list 122, the password 123 and the signature data 124are all blanks. The processing data generation unit 215 receives thedevice ID of its own terminal device, “ID_A,” from the device ID storageunit 22. The processing data generation unit 215 accepts, via theexternal input I/F 24, inputs of information on the its ownterminal-device: “unlimited” for the available number of accesses,“unlimited” for the access available time period, “unlimited” for theaccess available blocks, and “unlimited” for the access availableapplications, and generates the registration information 126.

Furthermore, the processing data generation unit 215 accepts, via theexternal input I/F 24, inputs of information on the PDA 30: “ID_B” forthe device ID, “3” for the available number of accesses, “Jan. 8,2004-Jun. 31, 2005” for the access available time period and “Block 2”for the access available blocks. Note here that an input of the accessavailable applications of the PDA 30 is not accepted, or alternativelyan input indicating that the PDA 30 does not have a right to access anyapplications is accepted. The processing data generation unit 215generates the registration information 127 from the acceptedinformation.

The processing data generation unit 215 generates the registration IDlist 125 from the registration information 126 and 127. The processingdata generation unit 215 outputs the generated registration ID list 125to the encryption unit 214, and receives, from the encryption unit 214,the encrypted registration ID list 122 which is generated by encryptingthe registration ID list 125.

The processing data generation unit 215 writes the encryptedregistration ID list 122 into the control information on theregistration requisition data.

The processing data generation unit 215 accepts an input of the password“PW_A” via the external input I/F 24, and writes the accepted password“PW_A” into the control information.

In addition, the processing data generation unit 215 receives thesignature data “Sig_A” from the signature generation unit 216A, andwrite the received signature data “Sig_A” into the control informationto generate the registration requisition data 120. The processing datageneration unit 215 outputs the registration requisition data 120 to therecord carrier 10 via the record carrier I/F 21.

(e-2) Generating Deletion Requisition Data 130

Here, a process of generating the deletion requisition data 130 shown inFIG. 5C is described as a specific example.

The processing data generation unit 215 holds in advance controlinformation on the deletion requisition data therein. The controlinformation is used for generating the deletion requisition data. In thecontrol information, only the deletion command 131 “/delete” of thedeletion requisition data 130 is written and the encrypted deletion IDlist 132, the password 133 and the signature data 134 are all blanks.

The processing data generation unit 215 accepts inputs of the device IDs“ID_C” and “ID_D” from the external input I/F 24, and generates thedeletion ID list 135 made up of “ID_C” and “ID_D.” The processing datageneration unit 215 outputs the deletion ID list 135 to the encryptionunit 214 and receives, from the encryption unit 214, the encrypteddeletion ID list 132 which is generated by encrypting the deletion IDlist 135.

The processing data generation unit 215 writes the encrypted deletion IDlist into the control information on the deletion requisition data.

The processing data generation unit 15 accepts an input of the password“PW_A′” via the external input I/F 24, and writes the accepted password“PW_A′” into the control information.

In addition, the processing data generation unit 215 receives thesignature data “Sig_A′” from the signature generation unit 216, andwrites the received signature data “Sig_A” into the control informationto generate the deletion requisition data 130. The processing datageneration unit 215 outputs the deletion requisition data 130 to therecord carrier 10 via the record carrier I/F 21.

(f) The signature generation unit 216 holds a signature key therein inadvance. The signature key corresponds to the verification key held bythe record carrier 10. The signature generation unit 216 generatessignature data by using the signature key to the registration command,the encrypted registration ID list and the password, all of which aregenerated by the processing data generation unit 215. The signaturegeneration unit 216 outputs the generated signature data to theprocessing data generation unit 215.

Note that the signature generation algorithm used in the signaturegeneration unit 216 corresponds to the signature verification algorithmused in the signature verification unit 108 of the record carrier 10,and is a digital signature standard using a public-key encryptionscheme.

(g) The access requisition generation unit 217 holds in advance controlinformation on an access requisition therein. The control information isused for generating the access requisition. In the control information,only the access command 161 “/access” of the access requisition 160 iswritten and the encrypted device ID 162 and the required-dataidentifying information 163 are blanks.

The following describes a process of generating the access requisition160 as a specific example. The access requisition generation unit 217receives, from the encryption unit 214, the encrypted device ID 162“E₅=(Kr, ID_A)” which is generated by encrypting the device ID of itsown terminal device, “ID_A,” and writes the received encrypted device ID162 into the control information on the access requisition. The accessrequisition generation unit 217 receives the required-data identifyinginformation 163 “address directory” via the external input I/F 24, andwrites the received required-data identifying information 163 into thecontrol information to generate the access requisition 160. The accessrequisition generation unit 217 outputs the generated access requisition160 to the record carrier 1Q via the record carrier I/F 21.

(h) The data output unit 218 receives data from the record carrier 10via the record carrier I/F 21, and outputs the received data to thedisplay unit 25.

2.4 External Input I/F 24

The external input I/F 24 is, specifically speaking, a plurality of keysprovided on the operating panel of the cellular phone 20. When the userpushes keys, the external input I/F 24 generates signals correspondingto the pushed keys and outputs the generated signals to the controller23.

2.5. Display Unit 25

The display unit 25 is specifically speaking a display unit, anddisplays the data outputted from the data output unit 218 on a display.

3. PDA 30

The PDA 30 is assumed to be a terminal device owned by the same user ofthe cellular phone 20. The PDA 30 has a card slot in which the recordcarrier 10 can be placed. In addition, the PDA 30 holds in advance thedevice ID of its own terminal device, “ID_B,” therein. Note that adiagram showing the structure of the PDA 30 is not presented since ithas the same structure as the cellular phone 20.

The PDA 30 differs from the cellular phone 20 in that the PDA 30 doesnot register device information with the record carrier 10, and onlymakes an access requisition. In the process of the access requisition,the PDA 30 reads out the device ID of its own terminal device, “ID_B,”and generates an encrypted device ID by encrypting the readout deviceID. The PDA 30 outputs to the record carrier 10 the access requisitionwhich includes the encrypted device ID.

The access requisition 170 shown in FIG. 8B is an example of the accessrequisition generated by the PDA 30. As shown in the figure, the accessrequisition 170 comprises an access command 171 “/access,” an encrypteddevice ID 172 “E₅(Kr, ID_B)” and required-data identifying information173 “protected mail data.”

4. PC 40

The PC 40 is assumed to be a terminal device owned by the same user ofthe cellular phone 20. The PC 40 has a card slot in which the recordcarrier 10 can be placed. In addition, the PC 40 holds in advance thedevice ID of its own terminal device, “ID_C,” therein. Note that adiagram showing the structure of the PC 40 is not presented since it hasthe same structure as the cellular phone 20.

As is the case of the PDA 30, the PC 40 does not register deviceinformation with the record carrier 10, and only makes an accessrequisition. In the process of the access requisition, the PC 40 readsout the device ID of its own terminal device, “ID_C,” and generates anencrypted device ID by encrypting the readout device ID. The PC 40outputs to the record carrier 10 the access requisition which includesthe encrypted device ID.

The access requisition 180 shown in FIG. 8C is an example of the accessrequisition generated by the PC 40. As shown in the figure, the accessrequisition 180 comprises an access command 181 “/access,” an encrypteddevice ID 182 “E₅ (Kr, ID_C)” and required-data identifying information183 “APP2.”

5. Cellular Phone 50

The cellular phone 50 is assumed to be a terminal device owned by adifferent individual from the user of the cellular phone 20, the PDA 30and the PC 40. The cellular phone 50 has a card slot in which the recordcarrier 10 can be placed. In addition, the cellular phone 50 holds inadvance the device ID of its own terminal device, “ID_E,” therein. Notethat a diagram showing the structure of the cellular phone 50 is notpresented since it has the same structure as the cellular phone 20.

The following assumes that the user of the cellular phone 50 attempts toaccess data stored in the record carrier 10 owned by a differentindividual by placing the record carrier 10 in the card slot of thecellular phone 50.

The cellular phone 50 reads out the device ID of its own terminaldevice, “ID_E,” and generates an encrypted device ID by encrypting thereadout device ID. The cellular phone 50 outputs an access requisitionincluding the generated encrypted device ID to the record carrier 10.

The access requisition 190 shown in FIG. 8D is an example of the accessrequisition generated by the cellular phone 50. As shown in the figure,the access requisition 190 comprises an access command 191 “/access,” anencrypted device ID 192 “E₅(Kr, ID_E)” and a required-data identifyinginformation 193 “image data.”

The record carrier 10 has not registered the cellular phone 50, which isa device of the other individual, with the access authorized devicetable 140. Therefore, even if the cellular phone 50 outputs the accessrequisition 190 to the record carrier 10, the cellular phone 50 cannotaccess the data of the record carrier 10 since the record carrier 10judges that the cellular phone 50 does not have a right to access thedata.

<Operations>

1. Overall Operations

FIG. 11 is a flowchart illustrating overall operations of the dataprotection system 1.

A requisition is raised (Step S1), and a process according to therequisition is conducted. In the case where the requisition at Step S1is “registration,” the registration process of device information isconducted (Step S2). When the requisition is “deletion,” the deletionprocess of device information is conducted (Step S3). When therequisition is “access,” the data access process is conducted (Step S4).When a required process is completed, the operations return to Step S1.

2. Registration Process of Device Information

FIG. 12A is a flowchart illustrating operations for the registrationprocess of device information performed between the record carrier 10and the cellular phone 20. Note that the operations described here aredetails of Step S2 in FIG. 11.

The cellular phone 20 accepts a process requisition indicating aregistration of device information (Step S10), and outputs aprocess-launch requisition to the record carrier 10 (Step S11). When therecord carrier 10 receives the process-launch requisition, achallenge/response verification is implemented between the recordcarrier 10 and the cellular phone 20 (Step S12). Subsequently, theregistration process is conducted (Step S13).

3. Deletion Process of Device Information

FIG. 12B is a flowchart illustrating operations for the deletion processof device information performed between the record carrier 10 and thecellular phone 20. Note that the operations described here are detailsof Step S3 in FIG. 11.

The cellular phone 20 accepts a process requisition indicating adeletion of device information (Step S20), and outputs a process-launchrequisition to the record carrier (Step S21). When the record carrier10: receives the process-launch requisition, a challenge/responseverification is implemented between the record carrier 10 and thecellular phone 20 (Step S22). Subsequently, the deletion process isconducted (Step S23).”

4. Challenge/Response Verification

FIG. 13 is a flowchart illustrating operations of the challenge/responseverification implemented between the record carrier 10 and the cellularphone 20. Note that the operations described here are details of Step512 in FIG. 12A and Step S22 in FIG. 12B.

First, by receiving an instruction to generate a random number from theprocess-launch requisition receiving unit 101, the random numbergeneration unit 102 of the record carrier 10 generates a random number r(Step S101). The random number generation unit 102 outputs the generatedrandom number r to the cellular phone 20 via the terminal I/F 11, andthe record carrier I/F 21 of the cellular phone 20 receives the randomnumber r (Step S102).

In addition, the random number generation unit 102 outputs the randomnumber r generated at Step S101 to the response data verification unit103. The response data verification unit 103 generates the encrypteddata C₁ by applying the encryption algorithm E₁ to the random number r,using the common key Kc held by the response data verification unit 103therein as an encryption key (Step 5103).

Meanwhile, the controller 23 of the cellular phone 20 receives therandom number r from the record carrier I/F 21, and generates responsedata C₁′ by applying the encryption algorithm E₁ to the random number r,using the common key Kc held by the response data verification unit 103therein as an encryption key (Step S104). The controller 23 outputs thegenerated response data C₁′ to the record carrier 10 via the recordcarrier I/F 21, the terminal I/F 11 of the record carrier 10 receivesthe response data C₁′ (Step S105).

The response data verification unit 103 compares the encrypted data C₁generated at Step S103 and the encrypted data C₁′ generated at Step S104by the cellular phone 20. When C₁ and C₁′ match (Step S106: YES), theresponse data verification unit 103 judges that the verification of thecellular phone 20 is successful (Step S107), and subsequently theregistration process or the deletion process is conducted between therecord carrier 10 and the cellular phone 20.

When C₁ and C₁′ do not match (Step S106: NO), the response dataverification unit 103 judges that the verification of the cellular phone20 is unsuccessful (Step S108), and outputs an error message informingthe cellular phone 20 accordingly via the terminal I/F 11. The recordcarrier I/F 21 of the cellular phone 20 receives the error message (StepS109). The controller 23 of the cellular phone 20 receives the errormessage from the record carrier I/F 21, and displays it on the displayunit 25 (Step S110).

5. Registration

5.1 Registration Process by Record Carrier 10

FIGS. 14 and 15 are flowcharts illustrating operations of theregistration process performed by the record carrier 10. Note that theoperations described here are details of Step S13 in FIG. 12A.

The public key acquisition unit 104 of the device informationregistration unit 14 acquires the public key PK₂₀ of the cellular phone20 (Step S202). By receiving an instruction from the response dataverification unit 103, the random key generation unit 105 generates therandom key Kr (Step S203).

The encryption unit 106 acquires the public key PK₂₀ of the cellularphone 20 and the random key Kr, and generates the encrypted random keyE₂(PK₂₀, Kr) by applying the encryption algorithm E₂ to the random keyKr using the public key PK₂₀ as an encryption key (Step S204). Theencryption unit 106 outputs the generated encrypted random key E₂(PK₂₀,Kr) to the cellular phone 20 via the terminal I/F 11 (Step S205).

Subsequently, the processing-data accepting unit 107 acceptsregistration requisition data from the cellular phone 20 (Step S206).The processing-data accepting unit 107 outputs the accepted registrationrequisition data to the signature verification unit 108.

The signature verification unit 108 receives the registrationrequisition data and extracts signature data from the receivedregistration requisition data (Step S207). The signature verificationunit 108 examines the signature data by using the verification key andthe signature verification algorithm on the extracted signature data(Step S208). When the verification of the signature data is unsuccessful(Step S209: NO), the signature verification unit 108 outputs an errormessage informing the cellular phone 20 accordingly via the terminal I/F11 (Step S214). When the verification of the signature data issuccessful (Step S209: YES), the signature verification unit 108 outputsthe registration requisition data to the password verification unit 109.

The password verification unit 109 receives the registration requisitiondata and extracts a password from the received registration requisitiondata (Step S210). Then, the password verification unit 109 reads out acorrect password stored in the device information storage unit 15 (StepS211), and judges whether or not the password extracted at Step S210 andthe correct password read out at Step S211 match.

When these two passwords do not match (Step S212: NO), the passwordverification unit 109 outputs, to the cellular phone 20 via the terminalI/F 11, an error message informing that the password verification isunsuccessful (Step S214). When the passwords match (Step S212: YES), thepassword verification unit 109 outputs the registration requisition datato the decryption unit 110.

The decryption unit 110 receives the registration requisition data, andextracts the encrypted registration ID list from the receivedregistration requisition data (Step S213). The decryption unit 110decrypts the encrypted registration ID list using the random keygenerated by the random key generation unit 105 (Step S215), and outputsthe decrypted registration ID list to the data controller 111.

The data controller 111 repeats Steps S216 to S222 with respect to eachset of registration information. The data controller 111 extracts adevice. ID from each set of the registration information (Step S217),and compares the device ID extracted at Step S217 with all device IDswhich have been registered with the access authorized device tablestored in the device information storage unit 15 (Step S218).

When a corresponding device ID is found in the access authorized devicetable (Step S219: YES), the data controller 111 outputs, to the cellularphone 20 via the terminal I/F 11, an error message informing that theterminal device identified by the device ID has been already registered(Step S220). When a corresponding device ID is not found in the accessauthorized device table (Step S219: NO), the data controller 111 writesthe registration information into the access authorized device tablestored in the device information storage unit 15 (Step S221).

5.2 Registration Process by Cellular Phone 20

FIGS. 16 and 17 are flowcharts illustrating operations of theregistration process performed by the cellular phone 20. Note that theoperations described here are details of Step S13 in FIG. 12A.

The decryption unit 213 of the controller 23 acquires, from the recordcarrier 10 via the record carrier I/F 21, the encrypted random key E₂(PK₂₀, Kr) which has been encrypted using the public key PK₂₀ of thecellular phone 20 (Step S233). The decryption unit 213 decrypts thereceived encrypted random key E₂(PK₂₀, Kr) to obtain the random key Kr(Step S234).

Subsequently, the cellular phone 20 repeats Steps S235 to 242 withrespect to each device to be registered.

The processing data generation unit 215 of the controller 23 acquires adevice ID of the device to be registered (Step S236). At this point, ifthe device to be registered is its own terminal device, i.e. thecellular phone 20, the processing data generation unit 215 acquires thedevice ID from the device ID storage unit 22. If the device to beregistered is another device, the processing data generation unit 215acquires the device ID from the external input I/F 24.

Next, the processing data generation unit 215 sets the available numberof accesses according to an input signal received from the externalinput I/F 24 (Step S237). Similarly, according to respective inputsignals received from the external input I/F 24, the processing datageneration unit 215 correspondingly sets the access available timeperiod (Step S238), the access available blocks (Step S239), and theaccess available applications (Step S240). The processing datageneration unit 215 generates one set of registration informationcomprising the device ID acquired at Step S236 and the data set at Steps237 to 240 (Step S241).

The processing data generation unit 215 generates a registration ID listincluding all sets of registration information that are generatedthrough repetitive operations of Steps S235 to S242 (Step S243).

The processing data generation unit 215 reads out the controlinformation on the registration requisition data (Step S244), and thenoutputs the registration ID list generated at Step S243 to theencryption unit 214. The encryption unit 214 receives the registrationID list and generates the encrypted registration ID list E₃(Kr,registration ID list) using the random key Kr decrypted at Step S234 asan encryption key on the received registration ID list (Step S245).

Next, the processing data generation unit 215 accepts an input of thepassword PW_A via the external input I/F 24 (Step S246). The signaturegeneration unit 216 generates the signature data Sig_A based on theregistration command, the encrypted registration ID list and thepassword (Step S247). The signature generation unit 216 outputs thegenerated signature data Sig_A to the processing data generation unit215.

The processing data generation unit 215 writes the encryptedregistration ID list, the password, and the signature data into thecontrol information on the registration requisition data so as togenerate the registration requisition data (Step S248). The processingdata generation unit 215 outputs the generated registration requisitiondata to the record carrier 10 via the record carrier I/P 21 (Step S249).

Afterwards, when receiving an error message (Step S250: YES), thecellular phone 20 displays the error message on the display unit 25 viathe data output unit 218 (Step S251). When not receiving the errormessage (Step S250: NO), the cellular phone 20 terminates the process.

6. Deletion

6.1 Deletion Process by Record Carrier 10

FIGS. 18 and 19 are flowcharts illustrating operations of the deletionprocess performed by the record carrier 10. Note that the operationsdescribed here are details of Step S23 in FIG. 12B.

The public key acquisition unit 104 of the device informationregistration unit 14 acquires the public key PK₂₀ of the cellular phone20 (Step S302). By receiving an instruction from the response dataverification unit 103, the random key generation unit 105 generates therandom key Kr (Step S303).

The encryption unit 106 receives the public key PK₂₀ of the cellularphone 20 and the random key Kr, and generates the encrypted random keyE₂ (PK₂₀, Kr) by applying the encryption algorithm E₂ to the random keyKr using the public key PK₂₀ as an encryption key (Step S304). Theencryption unit 106 outputs the generated encrypted random key E₂(PK₂₀,Kr) to the cellular phone 20 via the terminal I/F 11 (Step S305).

Subsequently, the processing-data accepting unit 107 accepts deletionrequisition data from the cellular phone 20 (Step S306). Theprocessing-data accepting unit 107 outputs the accepted deletionrequisition data to the signature verification unit 108.

The signature verification unit 108 receives the deletion requisitiondata and extracts signature data from the received deletion requisitiondata (Step S307). The signature verification unit 108 examines thesignature data using the verification key and the signature verificationalgorithm on the extracted signature data (Step S308). When theverification of the signature data is unsuccessful (Step S309: NO), thesignature verification unit 108 outputs an error message informing thecellular phone 20 accordingly via the terminal I/F 11 (Step S314). Whenthe verification of the signature data is successful (Step S309: YES),the signature verification unit 108 outputs the deletion requisitiondata to the password verification unit 109.

The password verification unit 109 receives the deletion requisitiondata, and extracts a password from the received deletion requisitiondata (Step S310). Then, the password verification unit 109 reads out acorrect password stored in the device information storage unit 15 (StepS311), and judges whether the password extracted at Step S310 and thecorrect password read out at Step 5311 match.

When these two passwords do not match (Step S312: NO), the passwordverification unit 109 outputs, to the cellular phone 20 via the terminalI/F 11, an error message informing that the password verification isunsuccessful (Step S314). When the passwords match (Step S312: YES), thepassword verification unit 109 outputs the deletion requisition data tothe decryption unit 110.

The decryption unit 110 receives the deletion requisition data, andextracts the encrypted deletion ID list from the received deletionrequisition data (Step S313). The decryption unit 110 decrypts theencrypted registration ID list using the random key generated by therandom key generation unit 105 (Step 5315), and outputs the decrypteddeletion ID list to the data controller 111.

The data controller 111 repeats Steps S316 to S322 with respect to eachdevice ID. The data controller 111 extracts a device ID from each set ofthe registration information (Step S317), and determines if the deviceID extracted at Step S317 has been registered with the access authorizeddevice table store in the device information storage unit 15 (StepS318).

When the same device ID is not found in the access authorized devicetable (Step S319: NO), the data controller 111 outputs, to the cellularphone 20 via the terminal I/F 11, an error message informing that theterminal device identified by the device ID has not been registered asan access authorized device (Step S321). When the same device ID isfound in the access authorized device table (Step S319: YES), the datacontroller 111 deletes a corresponding set of the access authorizeddevice information which includes the device ID from the accessauthorized device table stored in the device information storage unit 15(Step S320).

5.2 Deletion Process by Cellular Phone 20

FIG. 20 is a flowchart illustrating operations of the deletion processperformed by the cellular phone 20. Note that the operations describedhere are details of Step S23 in FIG. 12B.

The decryption unit 213 of the controller 23 acquires, from the recordcarrier 10 via the record carrier I/F 21, the encrypted random key E₂(PK₂₀, Kr) which has been encrypted using the public key PK₂₀ of thecellular phone 20 (Step S333). The decryption unit 213 decrypts thereceived encrypted random key E₂(PK₂₀, Kr) to obtain the random key Kr(Step S334).

The processing data generation unit 215 of the controller 23 acquiresdevice IDs of all terminal devices to be deleted (Step S335). At thispoint, if the device to be deleted is its own terminal device, i.e. thecellular phone 20, the processing data generation unit 215 acquires thedevice ID from the device ID storage unit 22. If the device to bedeleted is another device, the processing data generation unit 215acquires the device ID from the external input I/F 24. The processingdata generation unit 215 generates a deletion ID list made up of all ofthe acquired device IDs (Step S336).

The processing data generation unit 215 reads out the controlinformation on the deletion requisition data (Step S337), and thenoutputs the deletion ID list generated at Step S336 to the encryptionunit 214. The encryption unit 214 receives the deletion ID list, andgenerates the encrypted deletion ID list E₃(Kr, deletion ID list) usingthe random key Kr decrypted at Step S334 as an encryption key on thereceived deletion ID list (Step S338).

Next, the processing data generation unit 215 accepts an input of thepassword PW_A via the external input I/F 24 (Step S339). The signaturegeneration unit 216 generates the signature data Sig_A′ based on thedeletion command, the encrypted deletion ID list and the password (StepS340). The signature generation unit 216 outputs the generated signaturedata Sig_A′ to the processing data generation unit 215.

The processing data generation unit 215 writes the encrypted deletion IDlist, the password, and the signature data into the control informationon the deletion requisition data, and generates the deletion requisitiondata (Step S341). The processing data generation unit 215 outputs thegenerated deletion requisition data to the record carrier 10 via therecord carrier I/F 21 (Step S342).

Afterwards, when receiving an error message (Step S343: YES), thecellular phone 20 displays the error message on the display unit 25 viathe data output unit 218 (Step S344). When not receiving the errormessage (Step S343: NO), the cellular phone 20 terminates the process.

7. Access Process

FIG. 21 is a flowchart illustrating operations of the data accessprocess performed by the data protection system 1. Note that theoperations described here are details of Step S4 in FIG. 11.

A terminal device having a card slot in which the record carrier 10 isplaced accepts a requisition from the user to display given data (StepS401), and generates a process-launch requisition (Step S402). Theterminal device outputs the process-launch requisition to the recordcarrier 10, and the record carrier 10 receives the process-launchrequisition (Step S403).

The record carrier 10 acquires the public key PK_(N) of the terminaldevice (Step S404), where N=20, 30, 40 or 50. Next, the record carrier10 generates the random key Kr (Step S405). The record carrier 10generates the encrypted random key E₄ (PK_(N), Kr) by applying theencryption algorithm E₄ to the random key Kr generated at Step S405,using the public key PK_(N) acquired at Step S404 as an encryption key(Step S406). The record carrier 10 outputs the encrypted random key tothe terminal device, and the terminal device receives the encryptedrandom key (Step S407).

The terminal device decrypts the encrypted random key in order to obtainthe random key Kr (Step S408). Next, the terminal device reads out thedevice ID of its own terminal device stored therein (Step S409), andgenerates an encrypted device ID E₅ (Kr, device ID) by applying theencryption algorithm E₅ to the device ID using the random key Kr as anencryption key (Step S410).

Next, the terminal device reads out control information on an accessrequisition held therein in advance (Step S411), and writes theencrypted device ID and the access required-data identifying informationinto the control information on the access requisition to generate theaccess requisition (Step S412). The terminal device outputs the accessrequisition to the record carrier 10, and the record carrier 10 receivesthe access requisition (Step S413).

The record carrier 10 performs access authorization (Step S414), andoutputs the data to the terminal device based on the result of theaccess authorization. The terminal device receives the data outputtedfrom the record carrier 10 (Step S415), and displays the data (StepS416). Note that an error message, instead of the data required by theterminal device, is outputted at Step S415 depending on the result ofthe access authorization.

8. Access Authorization

FIGS. 22 and 23 are flowcharts illustrating operations of the accessauthorization performed by the record carrier 10. Note that theoperations described here are details of Step S414 in FIG. 21.

The decryption unit 155 of the controller 16 extracts an encrypteddevice ID from the access requisition (Step S500), and decrypts theencrypted device ID using the random key received from the random keygeneration unit 152 as a decryption key in order to obtain the device ID(Step S501). The decryption unit 155 outputs the decrypted device ID andthe access required-data identifying information to the judging unit156.

The judging unit 156 reads out the access authorized device table fromthe device information storage unit 15 and judges whether or not adevice ID same as the one received from the decryption unit 155 has beenregistered with the access authorized device table. When the same deviceID has not been registered (Step S502: NO), the judging unit 156outputs, to the terminal device via the terminal I/F 11, an errormessage informing that the access is denied (Step S510).

When the same device ID has been registered (Step S502: YES), thejudging unit 156 extracts a set of the access authorized deviceinformation which includes the device ID from the access authorizeddevice table (Step S503). The judging unit 156 extracts the availablenumber of accesses from the extracted access authorized deviceinformation and furthermore reads-out the number of times alreadyaccessed of the terminal device identified by the device ID (Step S504).

The judging unit 156 compares the number of times already accessed withthe available number of accesses. When the number of times alreadyaccessed is the same or more than the available number of accesses (StepS505: YES), the judging unit 156 outputs, to the terminal device via theterminal I/F 11, an error message informing that the access is denied(Step S510).

When the number of times already accessed is below the available numberof accesses (Step S505: NO), the judging unit 156 extracts the accessavailable time period from the access authorized device information andfurthermore acquires the date information from the date management unit157 (Step S506). The judging unit 156 judges whether or not the currenttime indicated by the date information is within the access availabletime period. The current time is outside the access available timeperiod (Step S507: NO), the judging unit 156 outputs, to the terminaldevices via the terminal I/F 11, an error message informing that theaccess is denied (Step S510).

When the current time is within the access available time period (StepS507: YES), the judging unit 156 refers to the table 200 held therein,and detects a memory block in which data identified by the receivedrequired-data identifying information is stored (Step S508).Furthermore, the judging unit 156 extracts the access available blocksfrom the access authorized device information (Step S509), and judgeswhether or not the memory block in which the data being required foraccess is stored is included in the access available blocks.

When the memory block is not included in the access available blocks(Step S511: NO), the judging unit 156 outputs, to the terminal devicevia the terminal I/F 11, an error message informing that the access isdenied (Step S517). When the memory block is included in the accessavailable blocks (Step S511: YES), the judging unit 156 judges from therequired-data identifying information whether or not the data beingrequired for access is an application program. If, the data beingrequired for access is not an application program (Step S512: NO), theprocess proceeds to Step S515.

If the data being required for access is an application program (StepS512: YES), the judging unit 156 extracts the access availableapplications from the access authorized device information (Step S513).The judging unit 156 judges whether or not the application program beingrequired for access is included in the access available applications.

When the application program being required for access is not includedin the access available applications (Step S514: NO), the judging unit156 outputs, to the terminal device vial the terminal I/F 11, an errormessage informing that the access is denied (Step S517).

When the application program being required for access is included inthe access available applications (Step S514: YES), the judging unit 156directs the memory access unit 158 to read out the data, and the memoryaccess unit 158 reads out the required data from the access-limited area13 in the data storage unit 12 (Step S515).

The data input/output unit 159 receives the data read out from thememory access unit 158, and outputs the data to the terminal device viathe terminal I/F 11 (Step S516).

[2] Modification of the First Embodiment

Here, a data protection system 1 a is described as a modification of thedata protection system 1, which is the first embodiment of the presentinvention.

FIG. 24 shows a structure of the data protection system 1 a. As shown inthe figure, the data protection system 1 a comprises a record carrier 10a, a cellular phone 20 a, a PDA 30 a, a PC 40 a, a cellular phone 50 aand a registration server 60 a.

In the data protection system 1, the cellular phone 20 is a devicededicated for requiring a registration and a deletion of deviceinformation to the record carrier 10. Here, having the registrationserver 60 a which requires the registration and deletion of deviceinformation of the record carrier 10 a is a feature of the dataprotection system 1 a.

1. Record Carrier 10 a

FIG. 25 is a functional diagram showing a structure of the recordcarrier 10 a.

As shown in the figure, the record carrier 10 a comprises a terminal I/F11 a, a data storage unit 12 a, an access-limited area 13 a, a deviceinformation registration unit 14 a, a device information storage unit 15a, a controller 16 a and a card ID storage unit 17 a. The structuraldifference from the record carrier 10 shown in FIG. 2 is that the recordcarrier 10 a has a card ID storage unit 17 a.

The terminal I/F 11 a, the data storage unit 12 a, the access-limitedarea 13 a, the device information storage unit 15 a and the controller16 a each have the same functions as the corresponding counterparts ofthe record carrier 10 of the first embodiment, i.e. the terminal I/F 11,the data storage unit 12, the access-limited area 13, the deviceinformation storage unit 15 and the controller 16, respectively.Therefore, the descriptions of these components are omitted.

The following description mainly focuses on differences of the recordcarrier 10 a from the record carrier 10.

The card ID storage unit 17 a stores a card ID “CID-A” for uniquelyidentifying the record carrier 10 a.

After implementing a challenge/response verification with theregistration server 60 a, discussed hereinafter, the device informationregistration unit 14 a receives registration requisition data/deletionrequisition data via the terminal device. Here, the same operationsshown in FIG. 13 are performed as the challenge/response verification,with “the record carrier 10” and “the cellular phone 20” substitutedwith “the record carrier 10 a” and “the registration server 60 a,”respectively.

The registration requisition data comprises a registration command, anencrypted registration ID list, a card ID, a device ID and signaturedata. The card ID is information for identifying the record carrier thatis the registration destination of the device information. The device IDis information for identifying a terminal device having the recordcarrier attached thereto, where the record carrier is a deletiondestination of the device information. The signature data is a digitalsignature generated based on the registration command, the encrypteddevice ID list, the card ID and the device ID. The registrationrequisition data 310 shown in FIG. 27A is an example of the registrationrequisition data.

The deletion requisition data comprises a deletion command, an encrypteddeletion ID list, a card ID, a device ID and signature data. The card IDis information for identifying the record carrier that is a deletiondestination of the device information. The device ID is information foridentifying a terminal device having the record carrier attachedthereto, where the record carrier is a deletion destination of thedevice information. The signature data is a digital signature generatedbased on the deletion command, the encrypted deletion ID list, the cardID and the device ID. The deletion requisition data 320 shown in FIG.27B is an example of the deletion requisition data.

The device information registration unit 14 a judges whether or not thecard ID included in the registration requisition data/the deletionrequisition data and the card ID stored in the card ID storage unit 17 amatch. The device information registration unit 14 a also judges whetheror not the device ID included in the registration requisition data/thedeletion requisition data and the device ID of the terminal devicehaving the record carrier 10 a attached thereto match.

Furthermore, the device information registration unit 14 a holds inadvance a verification key for verifying the signature data generated bythe registration server 60 a, verifies the signature data included inthe registration requisition data/the deletion requisition data usingthe verification key, and judges whether or not the registrationrequisition data/the deletion requisition data has been tampered.

When the card IDs match, and the device IDs match, and furthermore theverification of the signature data is successful, the device informationregistration unit 14 a conducts the registration process or the deletionprocess of the access authorized device information.

2. Cellular Phone 20 a

As shown in FIG. 26, the cellular phone 20 a comprises a record carrierI/F 21 a, a device ID storage unit 22 a, a controller 23 a, an externalinput I/F 24 a, a display unit 25 a and a communication I/F 26 a.

The record carrier I/F 21 a is, specifically speaking, a card slot, andthe record carrier 10 a is placed in the card slot.

The communication I/F 26 a is a network connection unit, and isconnected with the registration server 60 a via a network.

In response to a requisition from the record carrier 10 a, in theregistration and deletion processes of device information, the cellularphone 20 a outputs, to the record carrier 10 a, its own terminaldevice's device ID, which is stored in the device ID storage unit 22 a.

Although the cellular phone 20 of the first embodiment generates theregistration requisition data and the deletion requisition data, thecellular phone 20 a does not generate such requisition data. Instead,the cellular phone 20 a receives the registration requisition data andthe deletion requisition data generated by the registration server 60 avia a network, and outputs the received registration requisition dataand the deletion requisition data to the record carrier 10 a.

Since the data access process of the cellular phone 20 a is the same asthat of the cellular phone 20, the description is omitted.

3. PDA 30 a and PC 40 a

It is assumed that the PDA 30 a and the PC 40 a are terminal devicesowned by the user of the cellular phone 20 a.

The PDA 30 a and the PC 40 a have the same structure as the cellularphone 20 a. The PDA 30 a and PC 40 a both have card slots in which arecord carrier 10 a can be placed. In addition, both PDA 30 a and PC 40a have network connection units, and are connected with the registrationserver 60 a via a network.

In response to a requisition from the record carrier 10 a, in theregistration and deletion processes of device information, each of thePDA 30 a and the PC 40 a outputs its own terminal device's device IDstored therein to the record carrier 10 a.

The record carrier 10 of the first embodiment is capable of conductingthe registration and deletion processes of device information only whenit is attached to the cellular phone 20. According to the presentmodification, however, the PDA 30 a and PC 40 a receive the registrationrequisition data and the deletion requisition data generated by theregistration server 60 a via a network and output the receivedregistration requisition data and the deletion requisition data to therecord carrier 10 a in the same manner as the cellular phone 20 a.Hence, according to the present modification, the record carrier 10 a iscapable of conducting the registration and deletion processes of thedevice information even when it is attached to the PDA 30 a or the PC 40a.

Since the data access processes of the PDA 30 a and the PC 40 a are thesame as those of the PDA 30 and the PC 40, the descriptions are omitted.

4. Cellular Phone 50 a

It is assumed that the cellular phone 50 a is a terminal device owned bya different person other than the user of the cellular phone 20 a, thePDA 30 a and the PC 40 a.

The cellular phone 50 a has the same structure as the cellular phone 20a. The cellular phone 50 a has a card slot in which the record carrier10 a can be placed. Furthermore, the cellular phone 50 a has a networkconnection unit and can be connected to the registration server 60 a viaa network.

The cellular phone 50 a, which is a terminal device of anotherindividual, is not registered with the access authorized device table ofthe record carrier 10 a. Therefore, even if the cellular phone 50 aoutputs an access requisition to the record carrier 10 a, the cellularphone 50 a cannot access the data of the record carrier 10 a since therecord carrier 10 a judges that the cellular phone 50 a does not have aright to access the data.

5. Registration Server 60 a

The registration server 60 a is a server apparatus that requires aregistration and a deletion of device information to a record carrier,and has functions corresponding to the device information registrationand deletion of the cellular phone 20 according to the first embodiment.

As shown in FIG. 26, the registration server 60 a comprises an externalinput I/F 61 a, a controller 62 a and a data transmission unit 63 a.

The external input I/F 61 a accepts registration request data ordeletion request data of device information from outside.

The registration request data comprises: a registration instructionindicating a request regarding the registration process; a card ID foridentifying the record carrier that is the registration destination; adevice ID for identifying the terminal device having the record carrierattached thereto, where the record carrier is the registrationdestination; an available number of accesses; an access available timeperiod; access available blocks; access available applications; a username and a user password of the user requesting the registrationprocess; and transmission destination information.

The deletion request data comprises: a deletion instruction indicating arequest regarding the deletion process; a card ID for identifying therecord carrier that is the deletion destination; as device ID foridentifying the terminal device having the record carrier attachedthereto, where the record carrier is the registration destination; auser name and a user password of the user requesting the deletionprocess; and transmission destination information.

The external input I/F 61 a outputs the accepted registration requestdata or the deletion request data to the controller 62 a.

The controller 62 a has the same functions as the controller 23 of thecellular phone 20 according to the first embodiment. The controller 62 adiffers from the controller 23 in receiving a registration of the username and user password from the owner of the record carrier 10 a inadvance and storing these.

The controller 62 a receives the registration request data or thedeletion request data from the external input I/F 61 a, and verifies theuser by judging whether or not the user name and the password includedin the received registration request data/the deletion request datamatch the registered user name and the password, respectively. Only whenthe user authentication is successful, the controller 62 a generates theregistration requisition data based on the registration request data orgenerates the deletion requisition data based on the deletion requestdata.

FIG. 27A shows an example of the registration requisition data generatedby the controller 62 a. As shown in the figure, the registrationrequisition data 310 comprises: the registration command 311“/register”; the encrypted registration ID list 312 “E(Kr, registrationID list)”; the card ID 313 “CID_A”; the device ID 314 “ID_B”; and thesignature data 315 “Sig_A.” The card ID 313 “CID_A” and the device ID314 “ID_B” are respectively a card ID and a device TD included in theregistration request data received from the external input I/F 61. Theway of generating the encrypted registration ID list is the same as inthe case of the controller 23, and Kr used as an encryption key is therandom key generated in the record carrier 10 a. The controller 62 aoutputs, to the data transmission unit 63 a, the generated registrationrequisition data along with the transmission destination information.

FIG. 27B shows an example of the deletion requisition data generated bythe controller 62 a. As shown in the figure, the deletion requisitiondata 320 comprises: the deletion command 321 “/delete”; the encrypteddeletion ID list 322 “E(Kr, deletion ID list)”; the card ID 323 “CID_A”;the device ID 324 “ID_C”; and the signature data 325 “Sig_B.” The cardID 323 “CID_A” and the device ID 324 “ID_C” are respectively a card IDand a device ID included in the deletion request data received from theexternal input I/F 61. The way of generating the encrypted deletion IDlist is the same as in the case of the controller 23, and Kr used as anencryption key is the random key generated in the record carrier 10 a.The controller 62 a outputs, to the data transmission unit 63 a, thegenerated deletion requisition data along with the transmissiondestination information.

The data transmission unit 63 a is a network connection unit. The datatransmission unit 63 a receives the registration requisition data andthe transmission destination information from the controller 62 a, andtransmits, via a network, the received registration requisition data tothe terminal device indicated by the transmission destinationinformation. The data transmission unit 63 a receives the deletionrequisition data and the transmission destination information from thecontroller 62 a, and transmits, via a network, the received deletionrequisition data to the terminal device indicated by the transmissiondestination information.

As described above, the present modification is defined by that theregistration server 60 a, instead of the cellular phone 20 a, generatesthe registration requisition data and the deletion requisition data, andtransmits the generated registration requisition data and the deletionrequisition data to the record carrier 10 a via the terminal devicehaving the record carrier 10 a attached thereto. This allows to realizethe registration and deletion processes of device information not onlywhen the record carrier 10 a is attached to the cellular phone 20 a, butalso when it is attached to the PDA 30 a and to the PC 40 a.

Furthermore, the registration server 60 a is capable of preventing theuser of the cellular phone 50 a from registering unauthorized deviceinformation by implementing the user authentication in which the username and user password are required.

[3] Second Embodiment

The following gives a description of a data protection system 2according to a second embodiment of the present invention.

FIG. 28 shows a structure of the data protection system 2. As shown inthe figure, the data protection system 2 comprises a record carrier 10b, a cellular phone 20 b, a PDA 30 b, a PC 40 b, a cellular phone 50 band a management server 70 b.

In the data system 1, the record carrier 10 holds therein the accessauthorized device table indicating devices authorized to access therecord carrier 10. The data protection system 2 is defined by that themanagement server 70 b holds the access authorized device table whichindicates devices authorized to access the record carrier 10 b.

Note that a registration and a deletion of device information to themanagement server 70 b are conducted using the cellular phone 20 b.

<Structure>

1. Record Carrier 10 b

As shown in FIG. 29, the record carrier 10 b comprises a terminal I/F 11b, a data storage unit 12 b, an access-limited area 13 b, a controller16 b, a card ID storage unit 17 b and a tamper examination unit 18 b.

The record carrier 10 b does not have components corresponding to thedevice information registration unit 14 and the device informationstooge unit 15 of the record carrier 10, while the card ID storage unit17 b and the tamper examination unit 18 b are added to the recordcarrier 10.

Since the device I/F 11 b, the data storage unit 12 b and theaccess-limited area 13 b are the same as the terminal I/F 11, the datastorage unit 12 and the access-limited area 13 of the record carrier 10,respectively, descriptions for these are omitted. The followingdescription mainly focuses on differences of the record carrier 10 bfrom the record carrier 10.

The card ID storage unit 17 b stores a card ID “CID_A” for uniquelyidentifying the record carrier 10 b.

The tamper examination unit 18 b holds in advance a verification key forverifying signature data generated by the management server 70 b, andexamines the signature data outputted from the controller 16 b using theverification key in order to judge whether or not the data received bythe controller 16 b has been tampered. The tamper examination unit 18 boutputs the examination result of the signature data to the controller16 b.

When accepting an access requisition from a terminal device, thecontroller 16 b reads out the card ID from the card ID storage unit 17b, and transmits the readout card ID to the management server 70 b viathe terminal I/F 11 b, the terminal device and a network.

The controller 16 b acquires the access authorized device table and thesignature data from the management server 70 b, and outputs the acquiredsignature data to the tamper examination unit 18 b. When theverification of the signature data conducted by the tamper examinationunit 18 b is successful, the controller 16 b performs accessauthorization using the acquired access authorized device table. Theoperations of the access authorization are the same as in the case ofthe record carrier 10 of the first embodiment.

2. Cellular Phone 20 b

The cellular phone 20 b has the same structure as the cellular phone 20a of the data protection system 1 a. The cellular phone 20 b has anetwork connection unit, and is capable of connecting to the managementserver 70 b via a network.

As in the case of the cellular phone 20 of the first embodiment, thecellular phone 20 b is a device dedicated for registration and deletionprocesses of device information. The cellular phone 20 performs theregistration and deletion processes of device information with therecord carrier 10, however, the cellular phone 20 b performs theregistration and deletion processes of device information, not with therecord carrier 10 b, but with the management server 70 b that managesthe access authorized device table.

The cellular phone 20 b generates registration requisition dataincluding the card ID “CID_A” of the record carrier 10 b, and transmitsthe generated registration requisition data to the management server 70b. Similarly, the cellular phone 20 b generates deletion requisitiondata including the card ID “CID_A” of the record carrier 10 b, andtransmits the generated deletion requisition data to the managementserver 70 b.

In addition, the cellular phone 20 b has a card slot, and makes anaccess requisition to the record carrier 10 b when the record carrier 10b is placed in the card slot.

3. PDA 30 b, PC 40 b and Cellular Phone 50 b

The PDA 30 b, the PC 40 b, the cellular phone 50 b have the samestructures as the PDA 30 a, the PC 40 a and the cellular phone 50 a,respectively. Namely, each of these terminal devices has a networkconnection unit, and is capable of connecting with the management server70 via a network. Furthermore, each of these terminal devices has a cardslot and makes an access requisition to the record carrier 10 b when therecord carrier 10 b is placed in the card slot.

Note that these terminal devices do not conduct the registration anddeletion processes of device information to the management server 70 b.This is the same as in the case of the first embodiment.

4. Management Server 70 b

The management server 70 b has a device information registration unit 71b, a device information storage unit 72 b and a controller 73 b as shownin FIG. 29.

The device information registration unit 71 b has the same function andstructure as the device information registration unit 14 (FIG. 4) of therecord carrier 10 according to the first embodiment. Namely, whenreceiving the registration requisition data from the cellular phone 20b, the device information registration unit 71 b registers accessauthorized device information with the device information storage unit72 b based on the received registration requisition data. When receivingthe deletion requisition data from the cellular phone 20 b, the deviceinformation registration unit 71 b deletes access authorized deviceinformation from the device information storage unit 72 b based on thereceived deletion requisition data.

The device information storage unit 72 b stores the access authorizeddevice table. FIG. 30 shows an example of the access authorized devicetable. As shown in the figure, the access authorized device table 400has a data structure which is configured by adding a card ID 401 “CID_A”to the access authorized device table 140 (FIG. 6) of the firstembodiment.

In the first embodiment, since the record carrier 10 itself holds theaccess authorized device table 140, it is apparent that the accessauthorized device table 140 indicates terminal devices authorized toaccess the access-limited area 13 of the record carrier 10.

In the second embodiment, since the management server 70 b holds theaccess authorized device table 400, the card ID 401 indicates that thetable is information on terminal devices authorized to access theaccess-limited area of the record carrier 10 b which is identified bythe card ID “CID_A.”

When receiving the card ID “CID_A” from the record carrier 10 b via theterminal device and the network, the controller 73 b extracts the accessauthorized device table 400 including “CID_A” from the deviceinformation storage unit 72 b.

Furthermore, the controller 73 b holds in advance a signature key forgenerating signature data. The controller 73 b generates the signaturedata by using the signature key on the extracted access authorizeddevice table 400, and transmits the generated signature data along withthe access authorized device table 400 to the record carrier 10 b viathe terminal device and the network.

<Operations>

The following describes operations of the data protection system 2.

1. Overall Operations

FIG. 31 is a flowchart illustrating overall operations of the dataprotection system 2. First, a registration requisition/a deletionrequisition of device information is raised as a result of accepting aninput from the user (Step S601). The cellular phone 20 b transmits theregistration requisition/the deletion requisition to the managementserver 70 b via the network, and the management server 70 b receives theregistration requisition/the deletion requisition (Step S602) Next, themanagement server 70 b and the cellular phone 20 b conduct theregistration process/the deletion process (Step S603).

Subsequently, the cellular phone 20 b, the PDA 30 b, the PC 40 b or thecellular phone 50 b, any of which the record carrier 10 b is placed inits card slot accepts the input from the user, and thereby an accessrequisition is raised (Step S604). The terminal device outputs theaccess requisition to the record carrier 10 b, and the record carrier 10b receives the access requisition (Step S605). Then, the record carrier10 b and the management server 70 b conduct the data access process(Step S606).

2. Registration and Deletion Processes

Operations of the registration process by the cellular phone 20 b arethe same as those by the cellular phone 20 of the first embodiment(FIGS. 16 and 17). Additionally, operations of the deletion, process bythe cellular phone 20 b are the same as those by the cellular phone 20of the first embodiment (FIG. 20).

Furthermore, operations of the registration process by the managementserver 70 b are the same as those by the record carrier 10 of the firstembodiment (FIGS. 14 and 15), and operations of the deletion process bythe management server 70 b are the same as those by the record carrier10 of the first embodiment (FIGS. 18 and 19).

3. Data Access Process

FIG. 32 is a flowchart illustrating operations of the data accessprocess. The operations described here are details of Step S606 in FIG.31.

The controller 16 b of the record carrier 10 b reads out a card ID fromthe card ID storage unit 17 b (Step S701). The controller 16 b transmitsthe readout card ID to the management server 70 b via the terminal I/F11 b, the terminal device and the network. The controller 73 b of themanagement server 70 b receives the card ID (Step S702).

The controller 73 b extracts an access authorized device table includingthe received card ID from the device information storage unit 72 b (StepS703). Next, the controller 73 b generates signature data correspondingto the extracted access authorized device table (Step S704). Thecontroller 73 b transmits the access authorized device table and thesignature data to the record carrier 10 b via the terminal device andthe network, and the record carrier 10 b receives the access authorizeddevice table and the signature data (Step S705).

The tamper examination unit 18 b of the record carrier 10 b receives thesignature data received at Step S705, and examines the signature datausing a verification key held in the tamper examination unit 18 b (StepS706). When the verification of the signature data is unsuccessful (StepS707: NO), the tamper examination unit 18 b generates an error messageinforming that the data access is denied, and outputs the generatederror message to the terminal device (Step S708).

When receiving the error message, the terminal device displays thereceived error message on the display unit (Step S709).

When the verification of the signature data is successful (Step S707:YES), the tamper examination unit 18 b informs the controller 16 baccordingly. Then, the controller 16 b conducts access authorization(Step S710).

The terminal device displays, on the display unit, information receivedfrom the record carrier 10 b (Step S711). The information displayedreflects the result of the access authorization at Step 710.

4. Access Authorization

Operations of the access authorization performed by the record carrier10 b are the same as those performed by the record carrier 10 of thefirst embodiment (FIGS. 22 and 23).

[4] Other Modifications

(1) In the first embodiment, instead of the cellular phone 20, otherdedicated devices can be used for the registration of deviceinformation. For example, a case can be considered in which device IDsof devices authorized to access the record carrier would be registeredat the time of sale, using a special device at a cellular phone shop andsuch. In this case, the password entry at the time of registration isnot required.

(2) In the first and second embodiments, biometric information of theauthorized user may be included in the access authorized deviceinformation in advance. Then, the authorization for accessing theaccess-limited area is implemented, the record carrier may acquire theoperator's biometric information via the terminal device and judgewhether or not the acquired biometric information matches the biometricinformation registered with the access authorized device information.

Fingerprints, irises, and voiceprints can be thought of as the biometricinformation here.

(3) In the first and second embodiments, a password specified in advanceby the authorized user may be included in the access authorized deviceinformation. Then, the authorization for accessing the access-limitedarea is implemented, the record carrier may acquire, via, the terminaldevice, the password entered by the user and judge whether or not theacquired password matches the password registered with the accessauthorized device information.

Note here that the timing for implementing the password verification canbe varied. The password verification can be implemented, for example,for each access requisition, at regular time intervals, or immediatelyafter power on.

(4) In the second embodiment, the record carrier is connected to themanagement server through a network every time an access requisition israised, and accesses the access authorized device table. However, thisstructure is not necessarily required and the following structure may beadopted instead.

For example, the record carrier may access the management server atpredetermined time intervals regardless of the access requisition, ormay access the management server every time when the record carrier isplaced in a card slot of a different terminal device.

(5) In the modification of the first embodiment, the record carrier 10 aand the management server 60 a may implement the challenge-responseverification prior to the registration and deletion processes of deviceinformation.

(6) In the first embodiment, the record carrier conducts a registrationand a deletion of access authorized device information. Here, the recordcarrier may be configured so as not only to register and delete, butalso to update the access authorized device information.

Similarly, in the second embodiment, the management server may beconfigured so as not only to register and delete the access authorizeddevice information, but also to update this information.

(7) The present invention may be methods of accomplishing the abovedescribed data protection systems. The invention may be a computerprogram to realize these methods using a computer, or may be digitalsignals representing the computer program.

The present invention may also be a computer-readable storage medium,such as a flexible disk, a hard disk, a CD-ROM (Compact Disc Read OnlyMemory), MO (Magneto-Optical) disc, a DVD (Digital Versatile Disc), aDVD-ROM (Digital Versatile Disc Read Only Memory), a DVD-RAM (DigitalVersatile Disc Random Access Memory), a BD (Blu-ray Disc), or asemiconductor memory, on which the above-mentioned computer program ordigital signals are recorded. The present invention may also be thecomputer program or the digital signals recorded on such a storagemedium.

The present invention may also be the computer program or digitalsignals to be transmitted via networks, as represented bytelecommunications, wire/wireless communications, and the Internet.

The present invention may also be a computer system having amicroprocessor and a memory, wherein the memory stores the computerprogram, and the microprocessor operates according to the computerprogram.

The computer program or digital signals may be stored into the abovestorage medium and transferred to an independent computer system, oralternatively, may be transferred to an independent computer system viathe above network. Then, the independent computer system may execute thecomputer program or digital signals.

(8) The present invention includes a structure in which two or more ofthe above embodiments and modifications are combined.

INDUSTRIAL APPLICABILITY

The present invention can be utilized, for example in an electronicmoney system where IC cards are used, as a mechanism for preventingunauthorized use of the IC cards when the IC cards are lost or stolen.

1. A record carrier comprising: a storage unit; a requisition receivingunit operable to receive, from a terminal device having the recordcarrier attached thereto, a requisition for access to the storage unit;an acquisition unit operable to acquire an access condition indicatingwhether or not the terminal device is authorized to access the storageunit; a judging unit operable to judge whether or not the requisitionsatisfies the access condition; and a prevention unit operable toprevent the access of the terminal device to the storage unit when thejudging unit judges that the requisition does not satisfy the accesscondition.
 2. The record carrier of claim 1, further comprising: anaccess condition storage unit operable to store the access condition,wherein the acquisition unit acquires the access condition from theaccess condition storage unit.
 3. The record carrier of claim 2, whereinthe access condition include an identifier list including one or moreidentifiers which respectively identify one or more devices authorizedto access the storage unit, the requisition includes a requiring deviceidentifier for identifying the terminal device, and the judging unitjudges that, (i) when an identifier matching the requiring deviceidentifier is included in the identifier list, the requisition satisfiesthe access condition, and (ii) when an identifier matching the requiringdevice identifier is not included in the identifier list, therequisition does not satisfy the access condition.
 4. The record carrierof claim 2, wherein the access condition includes an identifier listincluding one or more identifiers and one or more sets of numberinformation which correspond one-to-one with the identifiersrespectively, the one or more identifiers identifying one or moredevices authorized to access the storage unit, each set of numberinformation indicating a count of accesses available for thecorresponding device to access the storage unit, the requisitionincludes a requiring device identifier for identifying the terminaldevice, the judging unit includes: a holding unit operable to hold acount of accesses indicating how many times the terminal device hasaccessed the storage unit; a 1st judging subunit operable to judgewhether or not an identifier matching the requiring device identifier isincluded in the identifier list; and a 2nd judging subunit operable tojudge, when the 1st judging subunit judges that the matching identifieris included, whether or not a count indicated by a set of numberinformation corresponding to the matching identifier is larger than thecount of accesses held by the holding unit, and the judging unit judgesthat, (i) when either one of a judgment result by the 1st judgingsubunit and a judgment result by the 2nd judging subunit, is negative,the requisition does not satisfy the access condition, and (ii) whenboth the judgment results are positive, the requisition satisfies theaccess condition.
 5. The record carrier of claim 2, wherein the accesscondition includes an identifier list including one or more identifiersand one or more sets of period information which correspond one-to-onewith the identifiers respectively, the one or more identifiersidentifying one or more devices authorized to access the storage unit,each set of period information indicating a time period available forthe corresponding device to access the storage unit, the requisitionincludes a requiring device identifier for identifying the terminaldevice, and the judging unit includes: a time managing unit operable tomanage a current date and time; a 1st judging subunit operable to judgewhether or not an identifier matching the requiring device identifier isincluded in the identifier list; and a 2nd judging subunit operable tojudge, when the 1st judging subunit judges that the matching identifieris included, whether or not the current time is within a time periodindicated by a set of period information corresponding to the matchingidentifier, and the judging unit judges that, (i) when either one of ajudgment result by the 1st judging subunit and a judgment result by the2nd judging subunit is negative, the requisition does not satisfy theaccess condition, and (ii) when both the judgment results are positive,the requisition satisfies the access condition.
 6. The record carrier ofclaim 2, wherein the storage unit includes a plurality of memory blocks,the access condition includes an identifier list including one or moreidentifiers and one or more sets of memory block information, whichcorrespond one-to-one with the identifiers respectively identifying oneor more devices authorized to access the storage unit, the sets ofmemory block information each indicating one or more of the memoryblocks available for each of the corresponding devices to access, therequisition includes a requiring device identifier for identifying theterminal device and memory block specifying information for specifyingone of the memory blocks, and the judging unit includes: a 1st judgingsubunit operable to judge whether or not an identifier matching therequiring device identifier is included in the identifier list; and a2nd judging subunit operable to judge, when the 1st judging subunitjudges that the matching identifier is included, whether or not thememory block specified by the memory block specifying information isincluded in the one or more of the memory blocks indicated by a set ofthe memory block information corresponding to the matching identifier,and the judging unit judges, that, (i) when either one of a judgmentresult by the 1st judging subunit and a judgment result by the 2ndjudging subunit is negative, the requisition does not satisfy the accesscondition, and (ii) when both the judgment results are positive, therequisition satisfies the access condition.
 7. The record carrier ofclaim 2, wherein the storage unit stores one or more sets of programdata, the access condition includes an identifier list including one ormore identifiers and one or more sets of program information, whichcorrespond one-to-one with the identifiers respectively identifying oneor more devices authorized to access the storage unit, the sets ofprogram information each indicating one or more sets of the program dataavailable for each of the corresponding devices to access, therequisition includes a requiring device identifier for identifying theterminal device and program specifying, information for specifying oneset of the program data, and the judging unit includes: a 1st judgingsubunit operable to judge whether or not an identifier matching therequiring device identifier is included in the identifier list; and a2nd judging subunit operable to judge, when the 1st judging subunitjudges that the matching identifier is included, whether or not the setof program data specified by the program specifying information isincluded in the one or more sets of the program data indicated by a setof the program information corresponding to the matching identifier, andthe judging unit judges that, (i) when either one of a judgment resultby the 1st judging subunit and a judgment result by the 2nd judgingsubunit is negative, the requisition does not satisfy the accesscondition, and (ii) when both the judgment results are positive, therequisition satisfies the access condition.
 8. The record carrier ofclaim 2, wherein the access condition includes (i) an identifier listincluding one or more identifiers which respectively identify one ormore devices authorized to access the storage unit, and (ii) abiometrics list including one or more sets of biometric information forrespectively identifying one or more users authorized to access thestorage unit, the requisition includes a requiring device identifier foridentifying the terminal device and operator biometric informationindicating biometric information of an operator of the terminal device,and the judging unit includes: a 1st judging subunit operable to judgewhether or not an identifier matching the requiring device identifier isincluded in the identifier list; and a 2nd judging subunit operable tojudge, when the 1st judging subunit judges that the matching identifieris included, whether or not a set of the biometric informationcorresponding to the operator biometric information is included in thebiometrics list, and the judging unit judges that, (i) when either oneof a judgment result by the 1st judging subunit and a judgment result bythe 2nd judging subunit is negative, the requisition does not satisfythe access condition, and (ii) when both the judgment results arepositive, the requisition satisfies the access condition.
 9. The recordcarrier of claim 2, wherein the access condition includes (i) anidentifier list including one or more identifiers which respectivelyidentify one or more devices authorized to access the storage unit, and(ii) a password list including one or more sets of password informationrespectively specified by one or more users authorized to access thestorage unit, the requisition includes a requiring device identifier foridentifying the terminal device and an entry password entered by anoperator of the terminal device, and the judging unit includes: a 1stjudging subunit operable to judge whether or not an identifier matchingthe requiring device identifier is included in the identifier list; anda 2nd judging subunit operable to judge whether or not a passwordindicated by a set of password information corresponding to the entrypassword is included in the password list, and the judging unit judgesthat, (i) when either one of a judgment result by the 1st judgingsubunit and a judgment result by the 2nd judging subunit is negative,the requisition does not satisfy the access condition, and (ii) whenboth the judgment results are positive, the requisition satisfies theaccess condition.
 10. The record carrier of claim 2, further comprising:an access condition accepting unit operable to accept the accesscondition from a terminal device having the record carrier attachedthereto; and an access condition registration unit operable to register,when the terminal device is authorized, the access condition with theaccess condition storage unit.
 11. The record carrier of claim 10,wherein the access condition registration unit includes: a 1st keyinformation holding unit holds 1st key information shared with theauthorized terminal device; and an output unit operable to outputchallenge data to the terminal device having the record carrier attachedthereto; and an examination unit operable to receive response data fromthe terminal device having the record carrier attached thereto andexamine the received response data, and the access conditionregistration unit authenticates that, when, as a result of theexamination, the response data is verified as data generated by usingthe challenge data and the 1st key information, the terminal devicehaving the record carrier attached thereto is the authorized terminaldevice.
 12. The record carrier of claim 11, wherein the access conditionaccepting unit accepts the access condition which has been encryptedusing an access condition encryption key, and the access conditionregistration unit decrypts the encrypted access condition based on theaccess condition encryption key, and registers the decrypted accesscondition with the access condition storage unit.
 13. The record carrierof claim 12, wherein the access condition accepting unit further acceptssignature data generated based on the access condition, and the accesscondition registration unit examines the signature data using averification key relevant to the authorized terminal device, andregisters, when the signature data is successfully verified, thedecrypted access condition with the access condition storage unit. 14.The record carrier of claim 13, wherein the access condition includes anidentifier list including one or more identifiers which respectivelyidentify one or more devices authorized to access the storage unit. 15.The record carrier of claim 13, wherein the access condition includes anidentifier list, the identifier list, comprises one or more identifiersand one or more sets of number information which correspond one-to-onewith the identifiers, the one or more identifiers respectively identifyone or more devices authorized to access the storage unit, and each setof number information indicates a count of accesses available for thecorresponding devices to access the storage unit.
 16. The record carrierof claim 13, wherein the access condition includes an identifier list,the identifier list comprises one or more identifiers and one or moresets of period information which correspond one-to-one with theidentifiers, the one or more identifiers respectively identify one ormore devices authorized to access the storage unit, and each set ofperiod information respectively indicates a time period available forthe corresponding device to access the storage unit.
 17. The recordcarrier of claim 13, wherein the storage unit comprises a plurality ofmemory blocks, the access condition includes an identifier list, theidentifier list comprises one or more identifiers and one or more setsof memory block information, which correspond one-to-one with theidentifiers, the identifiers respectively identify one or more devicesauthorized to access the storage unit, and the sets of memory blockinformation each indicate one or more of the memory blocks available foreach of the corresponding devices to access.
 18. The record carrier ofclaim 13, wherein the storage unit stores one or more sets of programdata, the access condition includes an identifier list, the identifierlist comprises one or more identifiers and one or more sets of programinformation, which correspond one-to-one with the identifiers, theidentifiers respectively identify one or more devices authorized toaccess the storage unit, and the sets of program information eachindicate one or more sets of the program data available for each of thecorresponding devices to access.
 19. The record carrier of claim 13,wherein the access condition includes an identifier list and abiometrics list, the identifier list comprises one or more identifiersrespectively identifying one or, more devices authorized to access thestorage unit, and the biometrics list comprises one or more sets ofbiometric information for respectively identifying one or more usersauthorized to access the storage unit.
 20. The record carrier of claim13, wherein the access condition includes an identifier list and apassword list, the identifier list comprises one or more identifiersrespectively identifying one or more devices authorized to access thestorage unit, and the password list comprises one or more sets ofpassword information respectively specified by one or more usersauthorized to access the storage unit.
 21. The record carrier of claim2, further comprising: a deletion requisition receiving unit operable toreceive, from the terminal device having the record carrier attachedthereto, a requisition for deletion of the access condition stored bythe access condition storage unit, an authentication unit operable toauthenticate whether or not the terminal device is authorized, and anaccess condition deletion unit operable to delete, when theauthentication unit authenticates that the terminal device isauthorized, the access condition from the access condition storage unitaccording to the requisition.
 22. The record carrier of claim 2, furthercomprising: an update requisition receiving unit operable to receive,from the terminal device having the record carrier attached thereto, arequisition for update of the access condition stored by the accesscondition storage unit, an authentication unit operable to authenticatewhether or not the terminal device is authorized, and an accesscondition update unit operable to update, when the authentication unitauthenticates that the terminal device is authorized, the accesscondition according to the requisition.
 23. The record carrier of claim1, further comprising: a communication unit operable to communicate withan access condition management server connected via a network, whereinthe acquisition unit acquires the access condition from the accesscondition management server via the communication unit.
 24. The recordcarrier of claim 23, wherein the acquisition unit acquires from theaccess condition management server via the communication unit, alongwith the access condition, signature data generated based on the accesscondition, and the record carrier further comprising: a tamper detectionunit operable to examine the signature data using a verification keyrelevant to the access condition management server, and detect whetheror not the access condition has been tampered; and a prohibition unitoperable to prohibit, when the tamper detection detects that the accesscondition has been tampered, the judging unit from judging
 25. Therecord carrier of claim 24, wherein the access condition includes anidentifier list including one or more identifiers which respectivelyidentify one or more devices authorized to access the storage unit, therequisition includes a requiring device identifier for identifying theterminal device, and the judging unit judges that, (i) when anidentifier matching the requiring device identifier is included in theidentifier list, the requisition satisfies the access condition, and(ii) when an identifier matching the requiring device identifier is notincluded in the identifier list, the requisition does not satisfy theaccess condition.
 26. The record carrier of claim 24, wherein the accesscondition includes an identifier list including one or more identifiersand one or more sets of number information which correspond one-to-onewith the identifiers respectively, the one or more identifiersidentifying one or more devices authorized to access the storage unit,each set of number information indicating a count of accesses availablefor the corresponding device to access the storage unit, the requisitionincludes a requiring device identifier for identifying the terminaldevice, the judging unit includes: a holding unit operable to hold acount of accesses indicating how many times the terminal device hasaccessed the storage unit; a 1st judging subunit operable to judgewhether or not an identifier matching the requiring device identifier isincluded in the identifier list; and a 2nd judging subunit operable tojudge, when the 1st judging subunit judges that the matching identifieris included, whether or not a count indicated by a set of numberinformation corresponding to the matching identifier is larger than thecount of accesses held by the holding unit, and the judging unit judgesthat, (i) when either one of a judgment result by the 1st judgingsubunit and a judgment result by the 2nd judging subunit is negative,the requisition does not satisfy the access condition, and (ii) whenboth the judgment results are positive, the requisition satisfies theaccess condition.
 27. The record carrier of claim 24, wherein the accesscondition includes an identifier list including one or more identifiersand one or more sets of period information which correspond one-to-onewith the identifiers respectively, the one or more identifiersidentifying one or more devices authorized to access the storage unit,each set of period information indicating a time period available forthe corresponding device to access the storage unit, the requisitionincludes a requiring device identifier for identifying the terminaldevice, and the judging unit includes: a time managing unit operable tomanage a current date and time; a 1st judging subunit operable to judgewhether or not an identifier matching the requiring device identifier isincluded in the identifier list; and a 2nd judging subunit operable tojudge, when the 1st judging subunit judges that the matching identifieris included, whether or not the current time is within a time periodindicated by a set of period information corresponding to the matchingidentifier, and the judging unit judges that, (i) when either one of ajudgment result by the 1st judging subunit and a judgment result by the2nd judging subunit is negative, the requisition does not satisfy theaccess condition, and (ii) when both the judgment results are positive,the requisition satisfies the access condition.
 28. The record carrierof claim 24, wherein the storage unit comprises a plurality of memoryblocks, the access condition includes an identifier list including oneor more identifiers and one or more sets of memory block information,which correspond one-to-one with the identifiers respectivelyidentifying one or more devices authorized to access the storage unit,the sets of memory block information each indicating one or more of thememory blocks available for each of the corresponding devices to access,the requisition includes a requiring device identifier for identifyingthe terminal device and memory block specifying information forspecifying one of the memory blocks, and the judging unit includes: a1st judging subunit operable to judge whether or not an identifiermatching the requiring device identifier is included in the identifierlist; and a 2nd judging subunit operable to judge, when the 1st judgingsubunit judges that the matching identifier is included, whether or notthe memory block specified by the memory block specifying information isincluded in the one or more of the memory blocks indicated by a set ofthe memory block information corresponding to the matching identifier,and judges that, (i) when either one of a judgment result by the 1stjudging subunit and a judgment result by the 2nd judging subunit isnegative, the requisition does not satisfy the access condition, and(ii) when both the judgment results are positive, the requisitionsatisfies the access condition.
 29. The record carrier of claim 24,wherein the storage unit stores one or more sets of program data, theaccess condition includes an identifier list including one or moreidentifiers and one or more sets of program information, whichcorrespond one-to-one with the identifiers respectively identifying oneor more devices authorized to access the storage unit, the sets ofprogram information each indicating one or more sets of the program dataavailable for each of the corresponding devices to access, therequisition includes a requiring device identifier for identifying theterminal device and program specifying information for specifying oneset of the program data, and the judging unit includes: a 1st judgingsubunit operable to judge whether or not an identifier matching therequiring device identifier is included in the identifier list; and a2nd judging subunit operable to judge, when the 1st judging subunitjudges that the matching identifier is included, whether or not the setof program data specified by the program specifying information isincluded in the one or more sets of the program data indicated by a setof the program information corresponding to the matching identifier, andjudges that, (i) when either one of a judgment result by the 1st judgingsubunit and a judgment result by the 2nd judging subunit is negative,the requisition does not satisfy the access condition, and (ii) whenboth the judgment results are positive, the requisition satisfies theaccess condition.
 30. The record carrier of claim 24, wherein the accesscondition includes (i) an identifier list including one or moreidentifiers which respectively identify one or more devices authorizedto access the storage unit, and (ii) a biometrics list including one ormore sets of biometric information for respectively identifying one ormore users authorized to access the storage unit, the requisitionincludes a requiring device identifier for identifying the terminaldevice and operator biometric information indicating biometricinformation of an operator of the terminal device, and the judging unitincludes: a 1st judging subunit operable to judge whether or not anidentifier matching the requiring device identifier is included in theidentifier list; and a 2nd judging subunit operable to judge, when the1st judging subunit judges that the matching identifier is included,whether or not a set of the biometric information corresponding to theoperator biometric information is included in the biometrics list, andjudges that, (i) when either one of a judgment result by the 1st judgingsubunit and a judgment result by the 2nd judging subunit is negative,the requisition does not satisfy the access condition, and (ii) whenboth the judgment results are positive, the requisition satisfies theaccess condition.
 31. The record carrier of claim 24, wherein the accesscondition includes (i) an identifier list including one or moreidentifiers which respectively identify one or more devices authorizedto access the storage unit, and (ii) a password list including one ormore sets of password information respectively specified by one or moreusers authorized to access the storage unit, the requisition includes arequiring device identifier for identifying the terminal device and anentry password entered by an operator of the terminal device, and thejudging unit includes: a 1st judging subunit operable to judge whetheror not an identifier matching the requiring device identifier isincluded in the identifier list; and a 2nd judging subunit operable tojudge whether or not a password indicated by a set of passwordinformation corresponding to the entry password is included in thepassword list, and judges that, (i) when either one of a judgment resultby the 1st judging subunit and a judgment result by the 2nd judgingsubunit is negative, the requisition does not satisfy the accesscondition, and (ii) when both the judgment results are positive, therequisition satisfies the access condition.
 32. The record carrier ofclaim 23, wherein the acquisition unit acquires, each time when therequisition receiving unit receives the requisition, the accesscondition from the access condition management server.
 33. The recordcarrier of claim 23, wherein the acquisition unit requires the accesscondition from the access condition management server at predeterminedtime intervals.
 34. The record carrier of claim 23, wherein theacquisition unit acquires, when it is detected that the record carrieris attached to a terminal device, the access condition from the accesscondition management server.
 35. A data protection system comprising: arecord carrier including: a storage unit, a requisition receiving unitoperable to receive, from a terminal device having the record carrierattached thereto, a requisition for access to the storage unit, anaccess condition storage unit operable to store an access conditionindicating whether or not the terminal device is authorized to accessthe storage unit, a judging unit operable to judge whether or not therequisition satisfies the access condition, and a prevention unitoperable to prevent the access to the storage unit when the judging unitjudges the requisition does not satisfy the access condition; and aterminal device including: a record carrier interface operable to attachthe record carrier thereto, an access requisition generation unitoperable to generate the requisition of the record carrier to thestorage unit, and an access requisition output unit operable to output,to the record carrier, the generated requisition for access.
 36. Thedata protection system of claim 35, further comprising: an accesscondition registration server operable to register the access conditionwith the access condition storage unit of the record carrier via theterminal device having the record carrier attached thereto.
 37. A dataprotection system comprising: a record carrier including, a storageunit, a requisition receiving unit operable to receive, from a terminaldevice having the record carrier attached thereto, a requisition foraccess to the storage unit, an access condition storage unit operable tostore an access condition indicating whether or not the terminal deviceis authorized to access the storage unit, a judging unit operable tojudge whether or not the requisition satisfies the access condition, anda prevention unit operable to prevent the access to the storage unitwhen the judging unit judges the requisition does not satisfy the accesscondition; a terminal device including, a record carrier interfaceoperable to attach the record carrier thereto, an access requisitiongeneration unit operable to generate the requisition of the recordcarrier to the storage unit, and an access requisition output unitoperable to output, to the record carrier, the generated requisition foraccess; and an access condition management server connected, via anetwork, with the terminal device having the record carrier attachedthereto, including, an access condition storage unit operable to storethe access condition, and an access condition transmission unit operableto transmit the access condition to the record carrier via the terminaldevice having the record carrier attached thereto.
 38. A data protectionmethod used by a record carrier including a storage unit and an accesscondition storage unit, comprising the steps of: (a) receiving, from aterminal device having the record carrier attached thereto, arequisition for access to the storage unit; (b) acquiring, from theaccess condition storage unit, an access condition indicating whether ornot the terminal device is authorized to access the storage unit; (c)judging whether or not the requisition satisfies the access condition;and (d) preventing the access to the storage unit when the step (c)judges that the requisition does not satisfy the access condition.
 39. Adata protection program used by a record carrier including a storageunit and an access condition storage unit, comprising the steps of: (a)receiving, from a terminal device having the record carrier attachedthereto, a requisition for access to the storage unit; (b) acquiring,from the access condition storage unit, an access condition indicatingwhether or not the terminal device is authorized to access the storageunit; (c) judging whether or not the requisition satisfies the accesscondition; and (d) preventing the access to the storage unit when thestep (c) judges that the requisition does not satisfy the accesscondition.
 40. A data protection method used by a record carrierincluding a storage unit, comprising the steps of: (a) receiving, from aterminal device having the record carrier attached thereto, arequisition for access to the storage unit; (b) communicating with anaccess condition management server connected via a network; (c)acquiring from the access condition management server, as a result ofthe step (b), an access condition indicating whether or not the terminaldevice is authorized to access the storage unit; (d) judging whether ornot the requisition satisfies the access condition; and (e) preventingthe access to the storage unit when the step (d) judges that therequisition does not satisfy the access condition.
 41. A data protectionprogram used by a record carrier including a storage unit, comprisingthe steps of: (a) receiving, from a terminal device having the recordcarrier attached thereto, a requisition for access to the storage unit;(b) communicating with an access condition management server connectedvia a network; (c) acquiring from the access condition managementserver, as a result of the step (b), an access condition indicatingwhether or not the terminal device, is authorized to access the storageunit; (d) judging whether or not the requisition satisfies the accesscondition; and (e) preventing the access to the storage unit when thestep (d) judges that the requisition does not satisfy the accesscondition.